Dodanie drugiej podsieci do VPN między lokalizacjami: dwie drogi
Tunele oparte na politykach wymagają zgodnych selektorów po obu stronach; tunele oparte na trasach wymagają trasy. Wybierz właściwą drogę i najpierw napraw trasę powrotną.
Dodanie drugiej podsieci do działającego tunelu między lokalizacjami zajmuje pięć minut w jednym projekcie i prawie całe popołudnie w drugim. Gdy tunel instaluje trasy dla podanych prefiksów, dodajesz trasę i ruch nią podąża. Gdy negocjuje jedną stałą parę selektorów, nowy prefiks pozostaje niechroniony, dopóki obie strony nie uzgodnią pasującej pary. Trzy rzeczy decydują: co naprawdę opisuje konfiguracja każdej strony, czy wynegocjowany ruch zawęża się do najmniejszej pasującej pary i kto jest właścicielem trasy powrotnej dla nowego zakresu.
Czytaj jądro, nie etykietę stanu
Tunel zgłaszający połączenie zainstalował co najmniej jedną asocjację podrzędną, ale niekoniecznie tę, którą myślisz. W Linux jądro pokazuje, co jest stosowane: ip xfrm policy wymienia pary selektorów, a swanctl --list-sas (lub starszy ipsec statusall) pokazuje, co strony wynegocjowały, w tym selektory ruchu w każdym kierunku. Jeśli nowego prefiksu nie ma w żadnym, jest niechroniony, cokolwiek mówi plik konfiguracyjny.
Porównaj to z tablicą tras. W układzie opartym na trasach urządzenie tunelu jest następnym skokiem dla chronionych prefiksów. Układ oparty na politykach często nie ma osobnej trasy do zdalnej podsieci, tylko trasę domyślną, bo ruch wybiera polityka, a nie tablica.
Oparte na politykach: obie strony muszą wymienić nowy prefiks
W terminologii strongSwan selektor mieszka w local_ts i remote_ts w konfiguracji podrzędnej, następcach leftsubnet i rightsubnet. Nowy prefiks musi pojawić się po obu stronach lustrzanie: to, co strona A nazywa lokalnym, strona B nazywa zdalnym. Rozbieżność rzadko daje czysty błąd. Strony zawężają się do przecięcia, stary prefiks działa dalej, a tylko nowy zawodzi po cichu.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyW pfSense lub OPNsense oznacza to drugi wpis Phase 2 łączący nową podsieć lokalną z nową zdalną, a potem zastosowanie. Zachowaj stary wpis; zastąpienie przenosi pierwotną podsieć zamiast ją dodawać. Jeśli istniejący Phase 2 pokrywa już supernet taki jak 0.0.0.0/0 lub zakres sumaryczny, nie dodawaj obok węższego wpisu: nakładające się selektory instalują konkurujące polityki, a kolejność oceny decyduje o zwycięzcy.
IKEv1 czyni każdą parę podsieci własnym Phase 2, a strona przyjmująca jedną parę na wymianę odrzuca resztę. IKEv2 może nieść kilka par selektorów w jednym podrzędnym, ale tylko jeśli obie implementacje je akceptują. Lista z swanctl --list-sas jest prawdą; to, co wpisałeś, jest prośbą.
Oparte na trasach: trasa jest polityką
Interfejs XFRM lub urządzenie VTI niesie ruch zgodnie z tablicą tras. Kierujesz nowy prefiks na urządzenie po obu stronach, a stan związany z transformacją interfejsu obowiązuje. Nie ma pary selektorów do synchronizacji, dlatego ten projekt skaluje się lepiej wraz ze wzrostem liczby podsieci. Przewodnik strongSwan po przekazywaniu omawia stronę jądra szczegółowo.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard idzie dalej. AllowedIPs jest jednocześnie listą dozwolonych kryptograficznie i, przez wg-quick, wpisem w tablicy tras. Dodaj prefiks tylko po jednej stronie, a otrzymasz uścisk dłoni, pakiety wychodzące i ciszę, bo druga strona odrzuca pakiety, których źródła nie ma na jej liście. Forma wg set zastępuje całą listę, więc powtórz prefiksy, które już działały, inaczej je odetniesz:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0To drugie polecenie nie jest opcjonalne, gdy użyłeś wg set zamiast wg-quick. Jądro przyjmuje nową listę od razu, ale nic nie dodaje dla niej trasy, więc ruch generowany lokalnie nadal wychodzi przez bramę domyślną. To najczęstszy powód, dla którego nowa podsieć WireGuard działa z hosta tunelu, a nie z laptopa.
Trasa powrotna zawodzi częściej niż tunel
Hosty w nowej zdalnej podsieci muszą wysyłać odpowiedzi przez bramę VPN. Gdy ta brama nie jest ich routerem domyślnym, odpowiedź idzie do routera LAN, który ją odrzuca lub przekazuje do internetu z prywatnym adresem źródłowym. Testuj z hosta po drugiej stronie, nie z bramy: ip route get 10.30.20.15 w Linux lub Find-NetRoute -RemoteIPAddress 10.30.20.15 w PowerShell pokazuje następny skok, którego host naprawdę użyje. Jeśli odpowiedź nie jest punktem końcowym tunelu, dodaj tam statyczną trasę dla nowego prefiksu.
NAT źródłowy po stronie bez trasy powrotnej jest legalną alternatywą i sposobem, w jaki wiele wdrożeń hub-and-spoke unika dotykania każdego serwera. Zastosuj go też do nowego prefiksu na bramie po stronie docelowej:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEKoszt jest realny. Zdalne logi przestają pokazywać pojedyncze adresy źródłowe, a reguły zapory oparte na pierwotnej podsieci zlewają się w jedną regułę dla bramy. Wybierz to świadomie, nie dlatego że brakowało trasy.
Zapory to druga połowa trasy powrotnej. Urządzenia strefowe nie rozszerzają automatycznie strefy istniejącego interfejsu tunelu na nową podsieć, a reguła napisana dla starego prefiksu nie będzie pasować. Dodaj nową podsieć do strefy lub pary reguł w obu kierunkach, zanim obwinisz IPsec.
Zdecyduj trzema pytaniami, potem zweryfikuj ruchem
Wersja skrócona: czy konfiguracja strony wymienia prefiksy (oparta na politykach), czy ruch jest routowany do interfejsu (oparta na trasach)? Czy oba końce wymieniają nowy prefiks? Czy istnieje droga powrotna z nowej podsieci do pierwotnego zakresu źródłowego?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
Weryfikacja to miejsce, w którym większość zmian zamyka się zbyt wcześnie. Ping z bramy dowodzi niewiele, bo brama wysyła od siebie i często pasuje do innej polityki niż host. Pinguj z hosta w nowej podsieci, potem uruchom aplikację, która wymusiła zmianę, i patrz na liczniki, nie na ikonę stanu.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showW tunelu opartym na politykach liczniki ip xfrm state powinny rosnąć w obu kierunkach; płaskie liczniki znaczą, że pakiet jest routowany, ale nie wybrany. W WireGuard wg show pokazuje transfer na stronę, a uścisk dłoni z zerem odebranych bajtów wskazuje listę drugiej strony lub jej trasę powrotną.
Zakończ, zapisując prefiks, selektor lub trasę strony, decyzję o trasie powrotnej i wpis zapory wraz z resztą inwentarza tunelu. Potem zrestartuj jedną bramę i przetestuj ponownie: trasa dodana ręcznie znika, a następna osoba nie powinna odkrywać tego od nowa.