Dlaczego wyniki skanowania portów zmieniają się za wyjściem VPN?

Uruchom tę samą kontrolę portu z linii biurowej i z wyjścia VPN, a obie odpowiedzi mogą się nie zgadzać co do adresu, którego nikt nie zmienił. Ta różnica bierze się z trasy i z tego, który host odpowiedział, a nie z tego, czy usługa działa. Trzy pytania rozdzielają te wyjaśnienia: o co naprawdę zapytała sonda, który host odpowiedział i co zapisał twój własny serwer. Przejdź przez nie w tej kolejności i zapisz każdą odpowiedź, zanim przejdziesz do następnej.

Napraw sondę, zanim porównasz dwa przebiegi

Słowo stanu można porównać z innym słowem stanu tylko wtedy, gdy oba pochodzą z tego samego eksperymentu. Pięć pól to ustala: adres źródłowy, który widziała dalsza strona, rozwiązany cel, port, typ skanowania i czas. Zmień którykolwiek z nich, a przeprowadziłeś drugi eksperyment, zamiast zmierzyć pierwszy dwa razy.

Sprawdź źródło przede wszystkim innym, bo klient VPN może działać, podczas gdy ruch nadal wychodzi przez interfejs fizyczny. Zapytaj dalszą stronę, co widzi, a potem zapytaj jądro, który interfejs wybrało:

curl -s https://ifconfig.me
ip route get 203.0.113.20

Dwa adresy w różnych sieciach oznaczają, że wyjaśnienie jest już w ręku, a reszta tych kontroli tylko je potwierdzi. Gdy się zgadzają, zapisz sondę z włączoną flagą przyczyny, aby stan wracał powiązany z wyjaśnieniem, zamiast stać samotnie jako gołe słowo. Typ skanowania również należy do tego zapisu, bo opisuje, o co pytano, a nie co wróciło. Stanu bez źródła, bez metody i bez znacznika czasu nie da się z niczym porównać:

nmap -sT -p 443,8443 --reason 203.0.113.20

Trzymaj to wyjście obok zapisu, a nie w buforze przewijania, którego następna osoba nie widzi. Dwa uczciwe skany, które się nie zgadzają, są sporem tylko wtedy, gdy nikt nie zapisał warunków. Po ustaleniu warunków albo wyniki się zgadzają i pytanie jest zamknięte, albo się różnią, a różnica jest faktem o trasie.

Ustal, który host zakończył uścisk dłoni

Zakończony uścisk dłoni dowodzi, że jakiś host go zakończył, a ten host nie musi być procesem, który masz na myśli. Balanser obciążenia, odwrotne proxy lub proxy SYN mogą odpowiedzieć, zanim zaangażowany będzie prawdziwy serwer, co jest zwykłym projektem, a nie objawem. Ważny certyfikat dla oczekiwanej nazwy też tego nie zawęża, bo certyfikat opisuje relację usługi i nic nie mówi o tym, która maszyna zakończyła połączenie.

Dokumentacja Nmap dotycząca stanów portów traktuje to jako podstawę: stan zapisuje, co sonda mogła zaobserwować z miejsca wysłania, a nie właściwość portu. Czytaj słowo stanu w ten sposób, a dwa przebiegi, które się nie zgadzały, zaczynają wyglądać spójnie, a nie sprzecznie, podczas gdy pytanie przesuwa się z tego, czy port jest otwarty, na to, kto przed nim stał.

Odpowiedz na drugie pytanie w backendzie, a nie z zewnątrz. Frontend, który przyjmuje połączenia, a potem nie dociera do swojego upstreamu, tworzy dokładnie zewnętrzny obraz zdrowej usługi z wolną aplikacją. Tylko własny zapis upstreamu rozdziela te dwa przypadki:

tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'

Linia logu pokazuje adres klienta, który aplikacja naprawdę widziała, a drugie polecenie pokazuje, czy proces trzymający port 443 to twoja aplikacja, czy coś przed nią. Jeśli te dwa nie zgadzają się co do tego, który adres się połączył, patrzysz na dwie nogi jednego żądania i bilet powinien to powiedzieć.

Sprawdź własne reguły, zanim obwinisz tunel

Zamierzona polityka jest najczęstszym powodem, dla którego port odpowiada w jednej sieci, a w innej nie, i jest najmniej ciekawym dostępnym wyjaśnieniem. Reguły dostępu istnieją po to, by zezwolić jednemu źródłu i odrzucić resztę, więc zmiana wyjścia jest dokładnie tym zdarzeniem, dla którego je napisano. Dlatego inny stan przez VPN nie pokazuje, że dostawca sprawdza ruch. Pokazuje, że twój adres źródłowy jest teraz inny, co jest znacznie mniejszym twierdzeniem.

Te reguły można przeczytać na serwerze, więc przeczytaj je, zamiast zgadywać o środku sieci. Wypisz reguły filtra, które wspominają którykolwiek z dwóch zakresów adresów, a potem sprawdź, czy połączenie w ogóle dotarło do demona:

nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113

Pusty drugi wynik jest informacyjny, bo nic nie dotarło do demona, a pytanie należy do filtra, grupy zabezpieczeń lub samej trasy. Trafienie oznacza, że usługa zobaczyła twoje źródło i wybrała swoją odpowiedź, a ta decyzja jest zwykle zapisana w regule, którą możesz przeczytać. Żaden wynik nie wspiera historii o dostawcy, a oba są tańsze do sprawdzenia niż przechwycenie pakietów.

Czytaj transport, certyfikat i odpowiedź osobno

Trzy warstwy dają trzy obserwacje, a sonda, która testuje jedną z nich, nie może relacjonować pozostałych dwóch. Trzymaj je jako osobne linie w zapisie, zamiast składać je w jeden wyrok, bo każda linia zawodzi na swój sposób, a tryb awarii mówi ci, gdzie patrzeć następnym razem.

Jedno polecenie tworzy pierwsze trzy wiersze wobec usługi, którą kontrolujesz. Umieść jego wyjście w zapisie obok skanowania, a nie w wiadomości czatu:

curl -v --resolve office.example:443:203.0.113.20 https://office.example/

Czytaj wyjście po kolei: uścisk dłoni odpowiada na pytanie o transport, temat certyfikatu na pytanie o nazwę, a treść odpowiedzi na pytanie o aplikację. Gdy linia uścisku dłoni się udaje, a linia odpowiedzi nie, masz frontend z zepsutym upstreamem, a nie zablokowany port. To inny bilet niż ten, który otworzyłeś, i warto to powiedzieć wprost.

Zakończ, wpisując w bilet cztery fakty: adres źródłowy, typ skanowania, host, który odpowiedział, i czas. Wszystko, czego potrzebuje późniejsze porównanie, żyje w tych czterech, a kto przejmie sprawę następny, nie będzie miał historii twojego terminala. Jeśli nie możesz wypełnić wszystkich czterech, przebieg nie jest zakończony.