Jak korzystać z dziurkowania UDP w tunelu / sesji SSH


21

Chcę wdrożyć Raspberry Pi w moim weekendowym domku. Raspberry Pi służy do rejestrowania temperatur i wysyłania ich do zdalnego serwera, który ma stały adres IP, zapisuje dane i wyświetla je na prostej stronie internetowej.

Może się jednak zdarzyć, że chcę coś zmienić w Raspberry Pi. Na przykład aktualizacje systemu lub zmiany w programie, który wysyła dane do serwera lub cokolwiek innego.

Przy proponowanej konfiguracji nie byłbym w stanie połączyć się z Raspberry Pi spoza jego sieci LAN.

UWAGA: Nie chcę zmieniać sieci, a istniejący router nie ma możliwości przekierowania portów, dynDNS ani VPN.

Niedawno przeczytałem o dziurkowaniu UDP. Podstawową ideą jest to, że klient wysyła pakiet UDP na znany adres serwera (tj. Z włączonym publicznym adresem IP lub dynDNS). Klient B, który chciałby połączyć się z klientem A, prosi serwer o publiczny adres IP i numer portu klienta A.

Następnie może połączyć się z klientem A bezpośrednio na jego publicznym adresie IP i dynamicznym porcie. Ponieważ klient A po raz pierwszy podłączył się do serwera na obecnie używanym porcie, NAT przekieruje pakiety do klienta A.

Mam nadzieję, że streściłem pomysł poprawnie, mniej więcej…

To wszystko brzmi ładnie, ale problem polega na tym, że nie jest to kwarantanna do pracy z połączeniem TCP, ponieważ router jest w stanie „zrozumieć” uzgadnianie połączenia TCP, a jeśli nie zostanie poprawnie zbudowane, nie prześle dalej paczki.

Jak więc mogę otworzyć sesję SSH od klienta B do klienta A, bez klienta A siedzącego za routerem z dynDNS, ze stałym publicznym adresem IP lub możliwością przekierowania portów? Użycie centralnego serwera z publicznym, stałym adresem IP lub nazwą domeny byłoby trudne.


Masz urządzenie internetowe, które potrafi dziurkować UDP, ale nie TCP? Zdobądź lepsze urządzenie NAT.
cpt_fink

Nie skończyłem ssh z udp, ale tutaj jest link na zarb.org/~gc/html/udp-in-ssh-tunneling.html
barlop

Nie wiem, ale zapytałem guru ssh, powiedzieli, że ssh może przekazywać udp, ale tylko wtedy, gdy działa jak VPN, i jest do tego przełącznik, powiedział, że to, -wale powiedział udp ponad tcp (być może przez to, że on obejmuje wszelkie próby przekazania udp za pomocą ssh), wiąże się z takimi problemami, jak duże opóźnienia i retransmisje rzeczy, których już nie chcesz. Sądzę jednak, że nadal warto spróbować. Widzę ten VPN za pośrednictwem ssh i -w wspomniano tutaj również wiki.archlinux.org/index.php/VPN_over_SSH
barlop

Jestem ciekawy, dlaczego nie chcesz otworzyć portu wejściowego? - to nie brzmi jak scenariusz wymagający super niesamowitych zabezpieczeń ... Alternatywnie, możesz mieć klienta A utrzymującego wychodzące połączenie SSH z odwrotnym wiązaniem portów do serwera, do którego klient B ma dostęp. W ten sposób możesz połączyć się za pośrednictwem serwera pośredniego. Jednak tego rodzaju ustalenia są podatne na awarie, a zatem są dość niepożądane, biorąc pod uwagę ograniczony fizyczny dostęp do ich rozwiązania w przypadku awarii.
kabadisha

Odpowiedzi:


8

pwnat


„.. nie jest trywialne nawiązanie połączenia z peerem za NAT ”.

„.. prawie wszystkie implementacje NAT odmawiają przekazywania ruchu przychodzącego , który nie odpowiada ostatnio pasującemu żądaniu wychodzącemu.


„.. pwnatNarzędzie jest autonomiczną implementacją autonomicznego przejścia NAT tylko w systemie GNU / Linux . Po skontaktowaniu się z serwerem za NAT, ustanawia kanał z semantyką TCP, używając pakietów UDP. Obsługuje zarówno klienta, jak i serwer za NAT (jeśli jeden z NAT pozwala na przesyłanie fałszywych [niestandardowych] komunikatów ICMP ). Ta implementacja jest skierowana do użytkowników końcowych.


  
użycie: ./pwnat <-s | -c> <args>

  -c tryb klienta
    <args>: [lokalny ip] <port lokalny> <host proxy> [port proxy (def: 2222)] <host zdalny> <port zdalny>

  -s tryb serwera
    <args>: [lokalny ip] [port proxy (def: 2222)] [[dozwolony host]: [dozwolony port] ...]

  -6 użyj IPv6  
  -v pokazuje wyjście debugowania (do 2)  
  -h pokaż pomoc i wyjdź  

Przykłady:  

    Strona serwera pozwalająca każdemu na proxy:
      ./pwnat -s

    Klient chce połączyć się z google.com:80:
      ./pwnat -c 8000 <pwnat.server.com> google.com 80
    Następnie przejdź do http: // localhost: 8000, aby odwiedzić google!  


pwnat;  schemat przepływu sieci


„Kluczowym pomysłem umożliwiającym serwer aby dowiedzieć się adres IP klienta jest dla serwera do okresowego wysyłania wiadomości do stałej, znanej adresu IP. Najprostsze podejście wykorzystuje komunikaty żądania echa ICMP do nieprzydzielone adres IP, takich jak 1.2.3.4 Ponieważ 1.2.3.4 nie jest przydzielone, ŻĄDANIE ICMP nie będzie kierowane przez routery bez domyślnej trasy. "

„W wyniku wiadomości wysłanych do 1.2.3.4 NAT umożliwi routing odpowiedzi w odpowiedzi na to żądanie. Klient łączący się następnie sfałszuje taką odpowiedź. W szczególności klient wyśle ​​komunikat ICMP wskazujący TTL_EXPIRED. Taki wiadomość może być zgodnie z prawem przesłana przez dowolny router internetowy, a adres nadawcy nie powinien być zgodny z docelowym adresem IP serwera.

Serwer nasłuchuje (fałszywych) odpowiedzi ICMP i po otrzymaniu inicjuje połączenie z adresem IP nadawcy określonym w odpowiedzi ICMP. Jeśli klient używa globalnie routowalnego adresu IP, jest to całkowicie bezproblemowe i można używać zarówno TCP, jak i UDP ustanowienie połączenia dwukierunkowego, jeśli klient nasłuchuje na wcześniej uzgodnionym porcie.

„(W przypadkach, w których nie ma wcześniej ustalonego portu, numer portu może w większości przypadków zostać przekazany jako część ładunku ICMP ECHO RESPONSE).”


Źródło: http://samy.pl/pwnat.pdf
https://github.com/samyk/pwnat


pwnat jest ledwo funkcjonalny nawet dla połączeń localhost z localhost. Mogę wysyłać i odbierać niektóre pakiety, ale do ustanawiania niezawodnych połączeń nie jest to bardzo przydatne.
Scott

@ Scott Cóż, to interesujący hack, ale tak naprawdę to tylko dowód koncepcji oparty na niewłaściwym użyciu i nadużywaniu protokołów sieciowych, takich jak ICMP. Nie polegałbym na tym. Jest stary i nieobsługiwany i nie polecałbym go używać. Nawet bym o tym nie wspominał, gdyby pytanie nie określało holepunchingu UDP. Jeśli chcesz być niezawodny, podłącz tunel VPN.
głosy

Nie narzekam, ale uważam, że „to rozwiązanie nie jest przeznaczone do użycia w środowisku produkcyjnym” jest użyteczną informacją dla każdego, kto tu przyjeżdża i szuka potencjalnie stabilnego rozwiązania.
Scott

@Scott To nie jest, nie do użytku w takim i takim środowisku. Wiele zastrzeżonych produktów wykorzystuje te techniki. W każdym razie jest tu wystarczająco dużo informacji, aby ludzie mogli podejmować własne decyzje. Nie polecam tego Ale używam tuneli VPN. Z drugiej strony niektóre sieci filtrują ruch VPN, więc musisz podejmować różne działania indywidualnie. Potrzebujesz pomocy w przejściu przez router NAT?
głosy

Mam aktualnie wykonalne rozwiązanie, używając odwrotnych tuneli ssh do połączenia dwóch maszyn NAT. Wymaga to jednak komputera „pośredniego”, który ma statyczny adres IP lub dla którego mogę skonfigurować przekierowanie portów na routerze. To pozwoliłoby mi odciąć tego pośrednika. No cóż.
Scott


0

Jest to dość brudne, ale łatwe rozwiązanie, ale co z używaniem netcata? Na Raspberry Pi możesz utworzyć skrypt, który zapętla polecenie:

nc <public_ip> <port1> | sh | nc <public_ip> <port2>  

Na lokalnym hoście wykonaj:

nc -l <port1>

I:

nc -l <port2>  

Będziesz mógł wpisać polecenie w pierwszej instancji, a odpowiedź zobaczyć w drugiej.


Jak to się ma do „dziurkowania UDP” ?
głosy

? w jaki sposób ten trawers NAT?
ZEE
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.