Czy można udostępnić tunel TCP w systemie Linux jako urządzenie znaków specjalnych?

Niedawno odkryłem w dokumentacji QNX, że pozwala ona konfigurować IPC oparty na komunikatach między procesami na osobnych maszynach fizycznych za pomocą serial device ( dev/serX) i zastanawiałem się:

Czy w Linuksie jest możliwe stworzenie ogólnosystemowego specjalnego urządzenia dla tunelu TCP / UDP? Coś takiego jak ncstdin / stdout publicznie ujawnione pod / dev / coś.

Na koniec chciałbym móc napisać coś do takiego pliku na jednym komputerze i otrzymać to na drugim końcu, na przykład:

#machine1:
echo "Hello" > /dev/somedev

#machine2:
cat < /dev/somedev

Spojrzałem na ncczłowieka, ale nie znalazłem żadnej opcji, aby określić źródło / miejsce docelowe inne niż stdio.

socat potrafi to zrobić i wiele innych rzeczy przypominających „strumienie”

Coś wykorzystującego ten podstawowy pomysł powinno zrobić to za Ciebie:

Machine1$ socat tcp-l:54321,reuseaddr,fork pty,link=/tmp/netchardev,waitslave

Machine2$ socat pty,link=/tmp/netchardev,waitslave tcp:machine1:54321

(dostosowany ze strony przykładów )

Jeśli chcesz zaszyfrować, możesz użyć wariacji ssl-l:54321,reuseaddr,cert=server.pem,cafile=client.crt,forkna maszynie1 i czegoś takiego jak ssl:server-host:1443,cert=client.pem,cafile=server.crtna maszynie2

(Więcej o socat ssl )

Przekazywanie wiadomości musi być realizowane na wyższej warstwie; TCP nie ma pojęcia wiadomości - połączenia TCP przesyłają strumienie oktetów.

Możesz osiągnąć coś w rodzaju żądanej nazwync i potoku nazwanego , zobacz man mkfifo; lub sprawdź, socatjak wskazuje Alex Stragies.

Bez usługi warstwy pośredniej podstawowymi problemami są (1) to, że danych nie można zapisać do sieci, chyba że ktoś na drugim końcu ich oczekuje i (2) że połączenia TCP są dwukierunkowe.

Ponieważ nie można zapisywać danych w sieci, chyba że ktoś ich słucha, zawsze należy uruchomić detektor, zanim będzie można wysłać dane. (W systemie przekazywania komunikatów proces obsługi komunikatów zapewni pewnego rodzaju buforowanie).

Twój przykład można łatwo przepisać:

• Najpierw uruchom detektor na maszynie2 (miejsce docelowe):

   nc -l 1234 | ...some processing with the received data...
  

  W twoim przykładzie byłoby to

   nc -l 1234 | cat
  

  Spowoduje to zablokowanie i poczekanie, aż ktoś wyśle ​​jakieś dane do portu 1234.

• Następnie możesz wysłać niektóre dane z maszyny1 (źródło):

  ...make up some data... | nc machine2 1234
  

  W twoim przykładzie byłoby to

   echo "Hello" | nc machine2 1234
  

Jeśli chcesz w jakiś sposób przetworzyć otrzymane dane i odpowiedzieć, możesz skorzystać z funkcji koprocesowania powłoki. Na przykład jest to bardzo prosty (i bardzo uparty) serwer WWW:

#! /bin/bash

while :; do
  coproc ncfd { nc -l 1234; }
  while :; do
    read line <&${ncfd[0]} || break
    line="$(
      echo "$line" |
      LC_ALL=C tr -cd ' -~'
    )"
    echo >&2 "Received: \"$line\""
    if [ "$line" = "" ]; then
      echo >&${ncfd[1]} "HTTP/1.0 200 OK"
      echo >&${ncfd[1]} "Content-Type: text/html"
      echo >&${ncfd[1]} "Connection: close"
      echo >&${ncfd[1]} ""
      echo >&${ncfd[1]} "<title>It works!</title>"
      echo >&${ncfd[1]} "<center><b>It works!</b></center>"
      echo >&${ncfd[1]} "<center>-- $(date +%Y-%m-%d\ %H:%M:%S) --</center>"
      break
    fi
  done
  kill %%
  sleep 0.1
done

Zobacz, w jaki sposób osiągnięto dwukierunkową komunikację między główną treścią skryptu a koprocesem za pomocą deskryptorów plików w tablicy $ncfd.

Jeśli chcesz po prostu połączyć dwa komputery za pomocą podstawowego programu, takiego jak nc, możesz przekierować z / do /dev/tcp/<host>/<port>.

To nie są rzeczywiste urządzenia, ale fikcja stworzona przez bash, więc rzeczy takie jak cat /dev/tcp/foo/19nie będą działać, ale cat < /dev/tcp/foo/19będą.