Dotrzeć do stacji roboczej za NAT bez przekierowania portu

Dwa punkty końcowe za NAT operatora i zablokowany router biurowy nie pozostawiają żadnego portu wejściowego do przekierowania, a odruchem jest i tak o niego poprosić. Lepszym pytaniem jest, która strona może wyjść na zewnątrz i której osiągalnej usłudze wolno przenosić ruch. Cztery projekty odpowiadają na to pytanie różnie i zawodzą na różne sposoby, gdy ścieżka jest zablokowana. Wybór między nimi to porównanie gwarancji, a nie nazw protokołów.

Cztery projekty, cztery różne obietnice

Poniższa tabela to krótka wersja. Czytaj środkową kolumnę jako obietnicę, którą możesz sprawdzić, a prawą jako obietnicę, której nikt nie złożył.

Który wiersz ma zastosowanie, zależy od zadania, a nie od preferencji. Jedna sesja pulpitu zdalnego, jedna powłoka administracyjna i dostęp do całej prywatnej podsieci to trzy wymagania, które nie potrzebują tego samego punktu wejścia, nawet gdy przypadkiem dotyczą tej samej maszyny.

Koncentrator zmienia to, kto wychodzi na zewnątrz, a nie to, co jest dozwolone

W projekcie z trasowanym koncentratorem zdalny laptop i stacja robocza, albo brama oddziału przed nią, otwierają każdy wychodzący tunel do usługi, którą obie mogą osiągnąć. Nic nie przyjmuje nieoczekiwanego połączenia na routerze stacji roboczej i właśnie dlatego ten projekt przetrwa NAT i działa nawet wtedy, gdy oddział nie ma adresu statycznego. Następnie koncentrator trasuje ruch między dwoma adresami wewnętrznymi zgodnie z własną polityką.

Kosztem jest to, że koncentrator musi istnieć, być osiągalny z obu stron i ktoś musi nim zarządzać. Filtrowanie ruchu wychodzącego musi dopuszczać transport, a sieć, która go blokuje, pokona projekt, nawet jeśli przekierowanie portu nie było potrzebne.

Subtelna część polega na tym, że osiągalność i autoryzacja to osobne decyzje podejmowane w różnych miejscach. Trasa do prefiksu nie mówi nic o tym, której usługi na stacji roboczej tożsamość może używać, a reguła zapory, która pozwala na tunel, nie mówi nic o tym, czy konto może się zalogować. Skonfiguruj oba, przetestuj oba i pozostaw decyzję o autoryzacji przy systemie, który posiada zasób, a nie przy tablicy tras.

Przejście działa tylko wtedy, gdy oba stosy je implementują

Przejście między równorzędnymi węzłami to zdolność konkretnego systemu, a nie ustawienie poprawiające VPN. Interactive Connectivity Establishment zbiera kilka adresów kandydujących i testuje pary, aż jedna zadziała: kandydaci hosta w interfejsach lokalnych, kandydaci refleksyjni serwera zbudowani z tego, co ujawnia NAT, oraz kandydaci przekaźnikowi przydzieleni na przekaźniku. Sam adres prywatny nie jest ścieżką, bo druga strona nie może do niego trasować.

Warto zrozumieć przypadek przekaźnikowy, zanim się go odrzuci. RFC 8656 opisuje TURN jako protokół, w którym klient prosi serwer o przekaźnikowy adres transportowy, a serwer przekazuje ruch między tym klientem a jego równorzędnymi węzłami. Przekaźnik przenosi więc dane, co zasadniczo różni się od katalogu, który tylko pomaga punktom końcowym się spotkać. Wymiana adresu przekaźnika z drugą stroną to krok koordynacji, który musi wykonać aplikacja.

Tego, czego nie możesz obiecać, to ścieżka bezpośrednia. Symetryczny NAT i niektóre zapory korporacyjne pokonują przebijanie dziur, a gdy tak się dzieje, system albo wraca do przekaźnika, albo zawodzi. Nie możesz też wnioskować, że dwa przetłumaczone punkty końcowe nigdy nie będą mogły rozmawiać; obsługiwany stos z zapasowym przekaźnikiem istnieje właśnie dlatego, że często mogą. Zdecyduj, czy ważniejsza jest dostępność, czy bezpośredniość, a potem sprawdź, którą ścieżkę faktycznie wybrało wdrożenie, zamiast zakładać korzystny przypadek.

Broker jest węższy niż sieć

Gdy wymaganiem jest jedna aplikacja, broker aplikacji lub połączenie odwrotne uruchomione przez stację roboczą mogą być najmniejszą odpowiedzią. Stacja robocza wychodzi na zewnątrz do brokera, broker uwierzytelnia zdalnego użytkownika i przenoszona jest tylko ta sesja aplikacji. Nie tworzy się żadna trasa do podsieci stacji roboczej, więc przejęcie sesji zdalnej nie dziedziczy ścieżki do każdego urządzenia obok.

Ta wąskość ma cenę: każda dodatkowa aplikacja potrzebuje własnej integracji, a wszystko, co aplikacja zakłada o sieci lokalnej, na przykład udział plików otwierany na pobliskim serwerze, może być nieosiągalne. Brokerzy koncentrują też politykę i rejestrowanie w jednym miejscu, co jest przydatne, dopóki to miejsce nie stanie się awarią.

Porównaj granice zaufania, a potem przetestuj ścieżkę

Koncentrator, który kończy tunele, może czytać ruch, który trasuje. Przekaźnik może przenosić niezależnie chronioną wymianę, gdy aplikacja szyfruje od końca do końca, a broker zwykle kończy sesję, którą prezentuje. Ustal, gdzie ochrona naprawdę się kończy, zanim uznasz, że dwa projekty są równoważne, bo oba są szyfrowane.

Następnie sprawdź, do czego stacja robocza faktycznie dociera na zewnątrz, bo każdy projekt powyżej od tego zależy. Uruchom to na stacji roboczej, zastępując nazwę hosta, której zamierzasz użyć.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Zaakceptuj projekt dopiero wtedy, gdy zamierzona operacja zdalna powiedzie się pod dozwoloną tożsamością, niezatwierdzona tożsamość zostanie odrzucona, a zachowanie przy niedostępnej ścieżce bezpośredniej lub przekaźnikowej jest znane i udokumentowane. Uwzględnij ponowne połączenie i normalny kontekst uruchamiania stacji roboczej, bo sesja rozpoczęta w biurze przez LAN nie testuje niczego, od czego zależy dostęp zdalny.