Wymagania dotyczące portów VPN: trzy wiersze do zapisania przed porównaniem

Listy portów dla usług VPN są kopiowane między stronami porównawczymi bez szczegółu, który decyduje, czy mają znaczenie: kto rozpoczyna połączenie. Reguła zezwalająca na wychodzący TCP 443 nic nie mówi o tym, czy inny host dotrze do nasłuchującego procesu na twojej maszynie. Napisz trzy osobne wymagania, zanim porównasz choćby jeden plan, i zaznacz, których twoje zadanie naprawdę potrzebuje. Większość porównań sprowadza się do jednego krótkiego pytania, gdy taka karta istnieje.

Rozdziel wymaganie, zanim przeczytasz jakąkolwiek listę portów

Trzy wiersze obejmują prawie każdy przypadek: dotarcie do celu poza tunelem, opublikowanie czegoś, aby inni mogli połączyć się do środka, oraz przenoszenie samego tunelu. Każdy wiersz zawodzi z innego powodu, a polityka dostawcy, która spełnia jeden, może pozostawić pozostałe dwa nietknięte. Przypisanie zadania do właściwego wiersza zajmuje pięć minut i oszczędza spór później.

Twierdzenia marketingowe celowo zacierają trzy wiersze. Zezwolenie P2P opisuje politykę celu, dedykowany adres opisuje adres, a twierdzenie o braku ograniczeń portów zwykle oznacza, że plan ich nie wymienia. Żadne z tych sformułowań nie odpowiada na pozostałe.

Wybierz jeden konkretny przepływ i zapisz go jako zdanie: inicjator, transport, port, rodzina adresów, kierunek. Nocny klient kopii zapasowych wysyłający na zdalny host jest tylko wychodzący. Serwer gry na twoim biurku, do którego dołączają znajomi, jest przychodzący. Puszczenie obu przez jeden tunel oznacza, że karta potrzebuje obu wierszy, a nie kompromisu między nimi.

Dostęp wychodzący zawodzi na polityce celu, nie na tunelu

Ruch wychodzący przez bramę tłumaczącą tworzy stan. Pierwszy pakiet z wewnętrznego adresu i portu buduje wpis tłumaczenia, a odpowiedzi pasują do niego, co jest zachowaniem mapowania opisanym w RFC 3022. Ten mechanizm jest powodem, dla którego karta przeglądarki zwykle działa bez żadnego żądania portu.

Dwie rzeczy wciąż to psują. Węzeł wyjściowy może filtrować cele lub numery portów, które uważa za podatne na nadużycie, a aplikacja może nasłuchiwać na porcie, którego polityka wyjściowa nigdy nie przewidziała. Pytaj o parę celów, nie o reguły wejściowe, i oczekuj różnych odpowiedzi dla TCP i UDP.

Zmierz, zanim zaczniesz się spierać. Uruchom to na maszynie, która będzie stała za tunelem, raz z tunelem wyłączonym i raz włączonym:

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://example.com

Te same polecenia, ten sam cel, dwa stany tunelu dają operatorowi porównanie przed i po, na którym może działać. Zastąp adres dokumentacyjny hostem, którego naprawdę potrzebujesz; ważne jest, aby porównanie się powtarzało, a nie to, czy jakaś liczba wygląda imponująco.

Publikacja przychodząca wymaga mapowania, adresu i czasu życia

Nic z zewnątrz nie może rozpocząć połączenia z twoim nasłuchującym procesem, chyba że coś po stronie publicznej wie, gdzie je dostarczyć. Statyczna rezerwacja portu trzymana przez operatora, mapowanie zamawiane przez klienta przez UPnP, NAT-PMP lub PCP oraz trasowany adres publiczny to trzy różne produkty o trzech różnych granicach.

Zadaj pięć pytań o każdy z nich: który protokół, który port zewnętrzny, czy port zewnętrzny może różnić się od lokalnego, którą rodzinę adresów obejmuje i jak długo mapowanie przeżywa ponowne połączenie. Rezerwacja powiązana z aktywną sesją znika, gdy ta sesja się kończy, cokolwiek mówi strona planu.

Najpierw potwierdź połowę lokalną, bo martwy nasłuch i zablokowana ścieżka przychodząca wyglądają z zewnątrz tak samo:

ss -lntup | grep -E ':(8080|51820)\b'
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

Gdy lokalne żądanie zwraca 200, a żądanie z sieci, której nie kontrolujesz, wciąż kończy się przekroczeniem czasu, luka jest po stronie publicznej. To moment, by podać operatorowi protokół i port zewnętrzny zamiast opisywać aplikację z nazwy.

Własny transport tunelu to osobne pytanie

Porty nośnika to najmniejsza część problemu i najłatwiejsza do sprawdzenia. Wartości domyślne różnią się w zależności od protokołu, a to, o czym klient może negocjować, liczy się bardziej niż jakikolwiek opis planu.

Sieć, która odrzuca wychodzący UDP, przyjmie tunel TCP 443 i odrzuci tunel UDP, więc tryb awaryjny należy do karty wymagań. Zmiana nośnika nie przenosi portu aplikacji wewnątrz tunelu i nie poszerza polityki celu; te pozostają w swoich wierszach.

Fragmentacja zasługuje na jedną próbę, póki tam jesteś, bo tunel, który się łączy, a potem zatyka przy dużych transferach, ma zwykle złą MTU, a nie zamknięty port:

ping -M do -s 1400 203.0.113.10
ping -M do -s 1372 203.0.113.10

W Windows ta sama próba to ping -f -l 1400 203.0.113.10. Ustaw MTU tunelu poniżej największego rozmiaru, który przechodzi, a potem ponownie sprawdź nieudany transfer.

Sprawdź trzy wiersze, zanim zapłacisz za plan

Połóż trzy wiersze na jednej stronie i wypełnij każdą komórkę zmierzonym wynikiem zamiast obietnicy. Te polecenia tworzą lokalną połowę tej strony w około minutę:

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
ping -M do -s 1400 203.0.113.10

Czytaj wynik jako listę kontrolną. Wychodzący działa, gdy cel odpowiada przy włączonym tunelu. Przychodzący działa tylko wtedy, gdy host spoza twojej sieci dotrze do nasłuchu na porcie zewnętrznym. Nośnik działa, gdy uzgadnianie kończy się na protokole, który dopuszcza twoja sieć dostępowa.

Dwa nawyki utrzymują kartę uczciwą. Zapisuj datę i wersję klienta obok każdego wyniku, bo zmieniają się i polityki dostawców, i wartości domyślne klientów. Potem proś o najwęższe mapowanie, które obsługuje przepływ, bo prośba o otwarcie wszystkiego zwykle przynosi odmowę lub dodatkową sprzedaż, a nie techniczną odpowiedź.