Dlaczego domowy NAT nie chroni interfejsu VPN
Domowy router przekazuje tunel, ale host ocenia odszyfrowany pakiet. Czytaj nasłuchiwacz, ścieżkę wewnętrzną i politykę wejściową osobno.
Laptopy za domowym routerem bez przekierowania portów nadal przyjmują połączenia SSH przychodzące przez VPN. To nie sprzeczność, bo dwa różne urządzenia oceniają dwa różne pakiety. Router przekazuje zaszyfrowany transport, a host decyduje, co zrobić z odszyfrowanym pakietem, który dociera do jego interfejsu tunelu. Rozdzielenie tych dwóch decyzji to całe ćwiczenie.
Router przekazuje tunel, host ocenia pakiet
Narysuj ścieżkę od zdalnego źródła do usługi, zanim spojrzysz na jedną regułę. Odcinek zewnętrzny to transport VPN, obsługiwany przez router i bramę. Odcinek wewnętrzny zaczyna się, gdy punkt końcowy zdejmuje warstwę tunelu, a host otrzymuje pakiet zaadresowany na jego adres VPN.
Połącz te dwa odcinki, a router zgarnie uznanie za decyzję, którą podejmuje host. Strona przekierowania portów albo log routera opisują tylko zewnętrzne rozmowy i żadne nie mówi, jaki odszyfrowany ruch host przyjmie. Host stosuje własną politykę wejściową do pakietu wewnętrznego, tak samo jak do każdego pakietu docierającego do interfejsu. Właśnie w tej polityce rozstrzyga się kwestia ekspozycji.
Nasłuchiwacz wieloznaczny nie jest usługą publiczną
W Linuksie powiązanie z INADDR_ANY oznacza każdy adres lokalny, więc usługa może odpowiadać na interfejsie tunelu, którego nigdy nie nazwała. Dokumentacja gniazd IP opisuje to powiązanie i warto ją przeczytać, zanim wyciągniesz wnioski z listy nasłuchiwaczy. Wpis wieloznaczny to fakt o gnieździe, a nie twierdzenie o osiągalności.
Dwie linie poniżej to ta sama usługa w dwóch różnych powiązaniach, a różnica jest całą odpowiedzią na pytanie, czy interfejs ma znaczenie. Najpierw przeczytaj, na jakim adresie siedzi gniazdo.
ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))Nazwij układ, który mógłby dotrzeć do portu
Trzy układy umieszczają pakiet na tym interfejsie i mają różnych właścicieli. Nazwanie właściwego decyduje, kto musi zmienić politykę.
| Arrangement | What reaches the port | Where the decision lives |
|---|---|---|
| Another permitted VPN peer | A packet from the same tunnel subnet | Gateway forwarding policy and host input rules |
| A deliberate public forward | Traffic the gateway publishes on purpose | Gateway service definition |
| A subnet routed behind the gateway | Client traffic from the far side | Gateway route and host input rules |
Wynik przeglądarki pokazujący publiczny adres wyjściowy nie mówi nic o żadnym z trzech, bo opisuje, jak ruch wychodzący wychodzi, a nie co wolno ruchowi przychodzącemu. Pracuj wstecz od nasłuchiwacza i adresu źródłowego w logu usługi. Jeśli źródłem jest inny peer tunelu, polityka bramy jest interesującym dokumentem. Jeśli to adres przetłumaczony, znajdź tłumaczenie, zanim zmienisz regułę.
Ogranicz usługę do zamierzonej ścieżki
Jeśli SSH jest potrzebny tylko ze ścieżki zarządzania, zapisz tę ścieżkę jako zakres źródłowy plus interfejs. Następnie ogranicz reguły wejściowe hosta według interfejsu, celu i źródła, a nie według nazwy sieci, ponieważ nazwa wyglądająca na prywatną może oznaczać dowolny adres. Zostaw trasę osobie, która naprawi następny problem.
nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter inputReguła, która nazywa interfejs tunelu i zakres zarządzania, wyraża intencję w jednym miejscu. Porównaj ją z regułą napisaną dla sieci Wi-Fi, która nie mówi nic o odszyfrowanym ruchu tunelu. Gdy obie warstwy się nie zgadzają, polityka hosta jest tą, którą spotyka pakiet.
Zostaw logowania i łatki dokładnie tam, gdzie są; dotarcie do portu nigdy nie było tym samym co pozwolenie na jego użycie. Zanotuj rodzinę adresów i czas dla każdego nieznanego źródła i zbadaj sprawę, zanim obwinisz funkcję lub podatność. Reguła, która wpuszcza każdego peera tunelu, to inny projekt niż ta, która wpuszcza podsieć zarządzania, i żadna linia logu nie powie, którą miano na myśli.
Przyjmij poprawkę z jednym sukcesem i jedną odmową
Udowodnij obie połowy: jedno zatwierdzone połączenie się udaje, a jedna wykluczona ścieżka zostaje odrzucona. Odmowa to ta połowa, którą ludzie pomijają, i to ona pokazuje, że reguła pracuje, zamiast stać obok zezwalającej wartości domyślnej. Testuj od wykluczonej strony, zamiast rozumować o tym.
Powtórz parę po ponownym połączeniu, bo tunel, który wraca z inną nazwą interfejsu, może po cichu ominąć regułę ograniczoną do starej. Granica, która ma znaczenie, to ta, którą host stosuje do pakietów, które faktycznie odbiera.