Jedna karta sieciowa czy dwie? Ustalanie układu interfejsów serwera VPN

Jeden fizyczny adapter wystarcza wielu serwerom VPN i nie jest to rozwiązanie uniwersalne. Zaszyfrowane połączenie trafia na ten adapter, proces VPN je odszyfrowuje, a następnie ruch wewnętrzny wychodzi przez interfejs wirtualny, zanim dotrze do lokalnej usługi lub trasowanego LAN-u. Czy to zadziała, zależy od trzech warunków: gdzie znajduje się cel, czy LAN ma drogę powrotną do puli klientów i czy jedno współdzielone łącze fizyczne daje izolację, którą deklarujesz. Odpowiedz na te trzy, a liczba adapterów wyniknie sama.

Trzy warunki, które o tym decydują

Pierwszy warunek to cel. Usługa na samym hoście VPN jest osiągalna wyłącznie przez interfejs tunelu, natomiast host w LAN wymaga przekazywania i drogi powrotnej. Drugi warunek to właśnie ta droga powrotna, bo urządzenie LAN musi wiedzieć, jak dotrzeć do puli klientów, albo trasą, albo przez tłumaczenie na serwerze.

Trzeci warunek to rozdzielenie. Jeden adapter oznacza, że każdy pakiet, zaszyfrowany czy nie, dzieli jedno łącze i zwykle jeden łańcuch polityk, więc twierdzenie o izolacji oparte na osobnym sprzęcie nie jest spełnione przez jeden interfejs. To fakt o ścieżce, a nie o tym, jak skonfigurowano system operacyjny. Nadal możesz filtrować ruch tunelu, ale nie możesz twierdzić, że masz granicę, której nie masz.

Żaden z tych trzech nie dotyczy liczby portów na obudowie. Dotyczą routingu, własności adresów i tego, jak bardzo projekt zależy od fizycznego rozdzielenia.

Dwa adaptery pozostają uzasadnionym wyborem, gdy strefy fizyczne, osobne łącza uplink, przepustowość lub droga odzyskiwania poza pasmem to uzasadniają. To konkretne wymagania i warto je zapisać, zanim ktokolwiek zamówi sprzęt.

Gdy usługa działa na hoście VPN

Najprostszy przypadek nie wymaga żadnego przekazywania. Demon odbiera pakiety klienta na interfejsie tunelu i przekazuje je do lokalnego gniazda, a odpowiedź wraca tą samą drogą. Dla hosta adres puli klientów jest prawdziwym adresem lokalnym.

Dwie rzeczy muszą jednak być poprawne: usługa musi nasłuchiwać na adresie osiągalnym dla tunelu, a zapora hosta musi akceptować ruch przychodzący na interfejs tunelu. Oba widać w poleceniach poniżej.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Przypisanie usługi tylko do adresu publicznego albo przypadkowe odfiltrowanie interfejsu tunelu daje połączenie, które dociera do hosta i tam ginie. Wygląda to jak awaria VPN, a zwykle jest decyzją dotyczącą gniazda lub zapory.

Gdy cel znajduje się w LAN

Tu projekt z jednym adapterem zyskuje opinię kłopotliwego. Serwer musi przekazywać pakiety klienta w stronę LAN, a urządzenie LAN musi odsyłać odpowiedzi do puli klientów. Albo niesiesz tę pulę jako trasę w LAN, albo tłumaczysz adres źródłowy na serwerze, żeby odpowiedzi wracały do samego serwera.

Obie odpowiedzi są uzasadnione i zawodzą inaczej. Trasa powrotna pozostawia oryginalny adres klienta widoczny dla celu, co jest dobre dla logów, a złe dla reguł zapory zakładających adresy LAN. Tłumaczenie utrzymuje LAN w prostocie i ukrywa tożsamość klienta przed celem.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Asymetryczna ścieżka to klasyczny objaw: żądanie klienta dociera, odpowiedź wychodzi innym routerem, a połączenie kończy się przekroczeniem czasu bez błędu po obu stronach. Przechwyć ruch po obu stronach, zanim wyciągniesz wniosek o tunelu.

Dlaczego alias nie tworzy drugiej strefy

Dodanie drugiego adresu do tego samego adaptera albo utworzenie interfejsu dummy imitującego drugi port zmienia bardzo niewiele. Pakiety nadal wychodzą tym samym łączem fizycznym, tym samym portem przełącznika i zwykle tym samym łańcuchem zapory, więc nie powstaje między nimi nowa granica. To wygoda konfiguracji, nie segmentacja. Traktowanie tego jako granicy strefy to sposób, w jaki twierdzenie o izolacji przeżywa tylko na papierze.

Osobna strefa wymaga rzeczywistego rozdzielenia na ścieżce i temu wymaganiu odpowiada drugi adapter. Jeśli reguła zależy od tego, że ruch w stronę VPN nigdy nie dzieli domeny rozgłoszeniowej z ruchem w stronę LAN, jeden kabel nie da tej właściwości, niezależnie od adresacji hosta.

Gdy produkt dokumentuje topologię wielointerfejsową dla konkretnego trybu, stosuj dokumentację tego produktu zamiast wymyślać obejście. Producenci zmieniają też obsługiwane topologie między wydaniami, co jest kolejnym powodem, by czytać aktualny przewodnik, a nie zrzut ekranu starego kreatora.

Sprawdź układ wobec ruchu, który dopuszczasz

Wypisz klasy ruchu, które serwer ma przenosić: klient do hosta, klient do LAN, host do LAN i zaszyfrowane połączenie zewnętrzne. Każda klasa ma źródło, cel i interfejs, a układ musi spełniać wszystkie cztery naraz. Projekt, który obsługuje trzy z nich, zwykle jest tym, który generuje zgłoszenia.

Następnie potwierdź rzeczywiste interfejsy i rzeczywiste przechwycenie, a nie diagram w dokumencie projektowym. Polecenia poniżej drukują oba widoki.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Jeśli przechwycenie zewnętrzne pokazuje ruch zaszyfrowany, a wewnętrzne pokazuje odszyfrowany ruch na interfejsie tunelu, podczas gdy fizyczny adapter przenosi oba, to jedna karta wykonuje pracę. Jeśli przechwycenie wewnętrzne jest puste, problem leży w tunelu lub w regułach przekazywania, a nie w liczbie adapterów. Ustal topologię na podstawie tych dwóch przechwyceń i tabeli routingu, a następna zmiana będzie miała do czego się odnieść.