Otwarcie portu VPN nie daje klientom dostępu do LAN

Tunel wstaje, klient się uwierzytelnia, ale LAN za bramą pozostaje niewidoczny. Reguła, która miała to naprawić, przepuszcza port VPN i działa dokładnie tak, jak zapisano, bo dotyczy pakietów adresowanych do samej bramy. Ruch klienta do hosta za bramą ma inny cel i inny łańcuch. Udane logowanie nie zmienia tego, który z dwóch łańcuchów sprawdza jądro.

Dwa łańcuchy, dwa różne cele

O losie pakietu decyduje to, dokąd idzie, a nie to, jak przyszedł. Ruch na adres bramy jest dostarczany lokalnie i oceniany przez reguły wejścia. Ruch, który brama przekazuje dalej, jest oceniany przez reguły przekazywania. To samo interfejs tunelu może tworzyć oba rodzaje pakietów, więc jedna reguła nie może objąć obu zadań.

Cały mit w jednym zdaniu: dopuszczenie nasłuchu nie mówi nic o dopuszczeniu sieci za nim. To dwie odrębne decyzje z odrębnymi dowodami, a nazwa interfejsu na obu ich nie łączy.

Co naprawdę dopuszcza reguła nasłuchu

Pakiety nasłuchu kończą się w procesie VPN i właśnie to umożliwia w ogóle zbudowanie tunelu. Strona administracyjna bramy i lokalna odpowiedź diagnostyczna również korzystają z własnej ścieżki wejścia hosta, dlatego test do bramy się udaje, a wszystko za nią zawodzi. Oba wyniki są poprawne i żaden nie dotyczy LAN.

Gdy proces dekapsuluje ruch klienta dla innego celu, pakiet wchodzi na ścieżkę przekazywania i potrzebuje tam zgody. Udane uwierzytelnienie rozstrzyga, kim jest klient; nie rozstrzyga, dokąd może iść. Oba pytania mają różnych właścicieli, różne logi i różne komunikaty o błędach.

Testuj z klienta, nigdy z bramy

Test wykonany na bramie idzie własną ścieżką wyjścia hosta i może przejść, gdy ścieżka przekazywania jest zamknięta. Zacznij test od klienta i obserwuj oba końce przepływu.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Jeśli żądanie pojawi się na tun0, a do celu nic nie dotrze, pakiet jest odrzucany po dotarciu, co wskazuje na reguły przekazywania albo na własne filtrowanie celu. Jeśli na tun0 nie pojawi się nic, klient nawet nie wysyła go do tunelu, a problem leży w routingu po stronie klienta, nie w polityce bramy. Porównaj to z żądaniem, które wychodzi poprawnie i nic nie zwraca, czyli z przypadkiem drogi powrotnej.

Przekazywanie wymaga trzech rzeczy, nie jednej

Przekazywanie w jądrze musi być włączone, reguła filtra musi przyjąć przepływ, a cel musi być osiągalny wraz z drogą powrotną dla odpowiedzi. Gdy brakuje jednego z trzech, cisza z punktu widzenia klienta jest taka sama.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Czytaj trzy wyniki razem. Zero w pierwszym czyni pozostałe dwa nieistotnymi, a domyślna polityka odrzucania w drugim odrzuca pakiety klienta, podczas gdy własny ruch bramy nadal działa. Trzeci wynik pokazuje, dlaczego reguła nasłuchu nigdy nie była problemem.

Trzymaj oba zestawy reguł osobno w dokumentacji

Zapisz regułę nasłuchu i regułę przekazywanej usługi w osobnych wierszach, z osobnymi właścicielami i uzasadnieniami. Gdy port VPN się zmienia albo publikowana jest nowa usługa, to rozdzielenie nie pozwala jednej zmianie po cichu rozszerzyć drugiej.

Zamiast traktować każdego uwierzytelnionego peera jako zaufanego członka LAN, używaj wąskich reguł dla tych zakresów klientów i usług, które ich potrzebują. Uwagi o przekazywaniu StrongSwana opisują stronę trasy powrotnej i tłumaczenia tej samej granicy, co jest znów trzecią decyzją.

Na koniec trzymaj warstwy prosto, gdy użytkownik jest odrzucany. Jeśli żądanie dociera do hosta, a aplikacja odrzuca konto, napraw uprawnienie aplikacji na tej warstwie; rozszerzenie przekazywania nie dostarczy poświadczeń do udostępniania plików i rozszerzy dostęp wszystkim innym, którzy połączą się poprawnie.