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.
-w
ale 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