Dlaczego adres tunelu VPN nie otwiera portu przychodzącego
Adres tunelu identyfikuje Twojego klienta wobec hostów równorzędnych, które mogą do niego routować, i nigdy nie tworzy nasłuchu. Sprawdź powiązanie, trasę powrotną, a potem politykę.
Połącz się z VPN biura, uruchom małą usługę na porcie 8443, wyślij adres tunelu koledze i obserwuj, jak połączenie zawodzi, podczas gdy klient nadal zgłasza połączenie. W tunelu nic nie jest zepsute: adres został przydzielony, sesja jest aktywna, a pakiety, które miałyby nieść odpowiedź, po prostu nigdy nie są przepuszczane. Wykonaj trzy kontrole poniżej w podanej kolejności i zatrzymaj się na tej, która zawodzi, bo każda ma inną poprawkę i tylko jedna z nich dotyczy VPN-u.
Zacznij od tego, gdzie gniazdo jest faktycznie powiązane
Zanim cokolwiek zostanie zroutowane, coś musi nasłuchiwać na adresie, do którego wywołujący może dotrzeć. Serwery deweloperskie są zwykłym winowajcą, bo wiele z nich domyślnie wiąże się z loopback i przyjmuje tylko połączenia pochodzące z tej samej maszyny. Adres tunelu nie zmienia tego powiązania, a system operacyjny odrzuci połączenie na długo przed tym, zanim VPN w ogóle wejdzie do gry.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Czytaj kolumnę adresu lokalnego, a nie stan. 127.0.0.1:8443 oznacza tylko loopback, a poprawką jest powiązanie z 0.0.0.0 albo z samym adresem tunelu. 0.0.0.0:8443 przyjmuje na wszystkich interfejsach, co jest szersze, niż większość zamierza, gdy maszyna ma też adres publiczny; 10.64.7.15:8443 to wąska wersja, która nasłuchuje tylko tam, gdzie kolega może dotrzeć. Zwróć uwagę także na nazwę procesu w tym samym wyniku, bo zabłąkana instancja z wcześniejszego testu to częsta przyczyna tego, że port wygląda na otwarty i odpowiada niewłaściwą treścią.
Potem zapytaj, czy cokolwiek może routować do tego adresu
Adres tunelu ma sens tylko dla hostów skonfigurowanych tak, by wysyłać ten prefiks do tunelu. Maszyna kolegi ma własną tablicę, a bez trasy do podsieci tunelu pakiet idzie do bramy domyślnej i ginie w miejscu, które nie ma pojęcia o istnieniu adresu. To pytanie o routing po stronie wywołującego, a nie uprawnienie po Twojej stronie.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Serwer między dwoma klientami liczy się równie mocno. W typowym projekcie dostępu zdalnego każdy klient otwiera połączenie wychodzące do bramy, a brama utrzymuje stan tych przepływów, więc odpowiedzi wracają trasą, którą już zna. Połączenie od jednego klienta do drugiego to nowy przepływ, który brama musi przyjąć i przekazać, a wiele wdrożeń wyłącza to celowo, aby utrzymać klientów odizolowanych od siebie. Usługi VPN dla konsumentów zwykle izolują domyślnie; bramy korporacyjne czasem pozwalają na to według grup.
Sprawdź kierunek, zanim cokolwiek zmienisz na hoście. Jeśli adres tunelu odpowiada z samej bramy, ale nie od partnera, różnicą jest ustawienie klient-do-klienta na bramie, a żadna edycja lokalnej zapory tego nie zastąpi.
Na koniec znajdź politykę, która zezwala na przepływ
Między zroutowanym pakietem a usługą, która odpowiada, leżą trzy warstwy polityki: decyzja o przekazywaniu serwera VPN, zapora hosta i dowolna grupa zabezpieczeń w chmurze przed instancją. Wszystkie trzy muszą się zgodzić, a zawodzą na różne sposoby, dlatego objaw z tabeli powyżej jest użyteczniejszy niż komunikat błędu w przeglądarce.
Zapora hosta to warstwa, o której ludzie zapominają po udanym powiązaniu, bo reguła zezwalająca na port na interfejsie LAN nie zezwala na niego automatycznie na interfejsie tunelu. Reguły ograniczone do interfejsu to poprawny projekt i zarazem częsta przyczyna usługi, która działa z biura, a nie z domu. Czytaj zakres reguły, a nie jej numer portu.
Filtrowanie stanowe wyjaśnia odwrotny przypadek. Połączenie wychodzące z Twojego laptopa tworzy stan, a odpowiedzi na nie są przepuszczane bez reguły przychodzącej. Połączenie kolegi to zupełnie nowy przepływ bez stanu za sobą, więc wymaga wyraźnego zezwolenia. Ta asymetria jest całym powodem, dla którego działająca sesja przeglądarki na Twojej własnej maszynie nic nie mówi o dostępności usługi z zewnątrz.
Gdy jedna kontrola zawiedzie, zmień projekt, a nie tunel
Jeśli wymaganiem jest, aby kolega otworzył Twoją lokalną usługę, uczciwą odpowiedzią jest zwykle mechanizm zbudowany do dostępu przychodzącego. Tunel SSH wsteczny jest najmniejszy: Twoja maszyna łączy się wychodząco z hostem, do którego kolega już dociera, a nasłuch istnieje na tym hoście.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Przekaźnik wymaga GatewayPorts clientspecified w konfiguracji serwera SSH, inaczej przekazany nasłuch wiąże się z loopback na przekaźniku i kolega napotyka tę samą odmowę co wcześniej. Dla wszystkiego, co trwa dłużej niż popołudnie, lepszym narzędziem jest balansujący obciążenie lub ingress z kontrolą stanu i certyfikatem dla opublikowanej nazwy, a tunel między lokalizacjami z trasami do obu podsieci jest właściwą odpowiedzią, gdy dwie sieci naprawdę muszą rozmawiać.
Każdy z tych projektów czyni ekspozycję jawną i o to chodzi. VPN przenosi pakiety między sieciami, do których i tak byłeś upoważniony; nie publikuje usługi i nie zamienia laptopa w host wystawiony do internetu. Zadaniem jest zdecydować, którą z trzech warstw zmienić, a tunel rzadko jest jedną z nich.