Lägga till ett andra subnät i en site-till-site-VPN: två vägar

Att lägga till ett andra subnät i en fungerande site-till-site-tunnel tar fem minuter i den ena designen och nästan en hel eftermiddag i den andra. När tunneln installerar rutter för de prefix du namnger lägger du till en rutt och trafiken följer den. När den förhandlar om ett fast selektorspar, förblir det nya prefixet oskyddat tills båda sidor enas om ett matchande par. Tre saker avgör: vad varje sidas konfiguration faktiskt beskriver, om den förhandlade trafiken snävas in till det minsta matchande paret, och vem som äger returrutten för det nya intervallet.

Läs kärnan, inte statusetiketten

En tunnel som rapporterar anslutning har installerat minst en barnassociationspost, men inte nödvändigtvis den du tror. På Linux visar kärnan vad som tillämpas: ip xfrm policy listar selektorsparen och swanctl --list-sas (eller äldre ipsec statusall) visar vad sidorna förhandlade, inklusive trafikselektorerna i varje riktning. Om det nya prefixet inte finns i någon av dem är det oskyddat, vad konfigurationsfilen än säger.

Jämför med rutttabellen. I en routbaserad lösning är tunnelenheten nästa hopp för de skyddade prefixen. En policybaserad lösning har ofta ingen egen rutt till det avlägsna subnätet, bara standardrutten, eftersom policyn väljer trafiken och inte tabellen.

Policybaserat: båda sidor måste lista det nya prefixet

I strongSwan-termer sitter selektorn i local_ts och remote_ts under barnkonfigurationen, efterföljarna till leftsubnet och rightsubnet. Det nya prefixet måste synas på båda sidor spegelvänt: det sidan A kallar lokalt kallar sidan B avlägset. Oöverensstämmelse ger sällan ett rent fel. Sidorna snävas in till snittet, det gamla prefixet fortsätter fungera och bara det nya misslyckas tyst.

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

På pfSense eller OPNsense innebär det en andra Phase 2-post som parar det nya lokala subnätet med det nya avlägsna, och sedan tillämpning. Behåll den gamla posten; att ersätta den flyttar det ursprungliga subnätet i stället för att lägga till. Om en befintlig Phase 2 redan täcker ett supernät som 0.0.0.0/0 eller ett sammanfattat intervall, lägg inte till en smalare post bredvid: överlappande selektorer installerar konkurrerande policyer och utvärderingsordningen avgör vinnaren.

IKEv1 gör varje subnätspar till sin egen Phase 2, och en sida som tar ett par per utbyte slänger resten. IKEv2 kan bära flera selektorspar i ett barn, men bara om båda implementationerna accepterar dem. Listan från swanctl --list-sas är sanningen; det du skrev är en begäran.

Routbaserat: rutten är policyn

Ett XFRM-gränssnitt eller en VTI-enhet bär trafik enligt rutttabellen. Du pekar det nya prefixet mot enheten på båda platserna, och tillståndet som är bundet till gränssnittets transformering gäller. Det finns inget selektorspar att synkronisera, därför skalar designen bättre när subnäten blir fler. strongSwans vidarebefordringsguide går igenom kärnsidan i detalj.

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

WireGuard går längre. AllowedIPs är både kryptotillåtelselistan och, via wg-quick, posten i rutttabellen. Lägg till prefixet bara på ena sidan och du får handskakning, utgående paket och tystnad, eftersom den avlägsna sidan kastar paket vars källa inte finns på dess lista. Formen wg set ersätter hela listan, så upprepa prefixen som redan fungerade, annars skär du av dem:

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 wg0

Det andra kommandot är inte valfritt när du använde wg set i stället för wg-quick. Kärnan accepterar den nya listan direkt, men ingenting lägger till en rutt för den, så lokalt genererad trafik går fortfarande ut via standardgatewayen. Det är den vanligaste orsaken till att ett nytt WireGuard-subnät fungerar från tunnelvärden och inte från en bärbar dator.

Returrutten misslyckas oftare än tunneln

Värdar på det nya avlägsna subnätet måste skicka svar tillbaka genom VPN-gatewayen. När den gatewayen inte är deras standardrouter går svaret till LAN-routern, som antingen kastar det eller vidarebefordrar det till internet med en privat källadress. Testa från en värd på den avlägsna sidan, inte från gatewayen: ip route get 10.30.20.15 på Linux eller Find-NetRoute -RemoteIPAddress 10.30.20.15 i PowerShell visar nästa hopp som värden faktiskt använder. Om svaret inte är tunnelns ändpunkt, lägg till en statisk rutt för det nya prefixet där.

Käll-NAT på platsen som saknar returrutt är ett legitimt alternativ och sättet många hub-and-spoke-utrullningar undviker att röra varje server. Använd det också på det nya prefixet på gatewayen på målsidan:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

Kostnaden är verklig. Fjärrloggar slutar visa individuella källadresser, och brandväggsregler knutna till det ursprungliga subnätet faller samman till en regel för gatewayen. Välj det medvetet, inte för att en rutt saknades.

Brandväggar är den andra halvan av returrutten. Zonbaserade enheter utökar inte automatiskt zonens gränssnitt till ett nytt subnät, och en regel skriven för det gamla prefixet matchar inte. Lägg till det nya subnätet i zonen eller regelparet i båda riktningarna innan du skyller på IPsec.

Avgör med tre frågor, verifiera sedan med trafik

Kortversionen: namnger sidans konfiguration prefix (policybaserat), eller routas trafiken in i ett gränssnitt (routbaserat)? Listar båda ändarna det nya prefixet? Finns en väg tillbaka från det nya subnätet till det ursprungliga källintervallet?

Verifieringen är där de flesta ändringar stängs för tidigt. En ping från gatewayen bevisar lite, eftersom gatewayen skickar från sig själv och ofta matchar en annan policy än en värd. Pinga från en värd på det nya subnätet, kör sedan applikationen som motiverade ändringen och titta på räknare i stället för en statusikon.

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

På en policybaserad tunnel ska ip xfrm state-räknarna stiga i båda riktningarna; platta räknare betyder att paketet routas men inte väljs. På WireGuard rapporterar wg show överföringen per sida, och en handskakning med noll mottagna byte pekar på den avlägsna sidans lista eller dess returrutt.

Avsluta med att registrera prefixet, sidans selektor eller rutt, beslutet om returrutten och brandväggsposten tillsammans med resten av tunnelinventeringen. Starta sedan om en gateway och testa igen: en rutt som lagts till för hand försvinner, och nästa person bör inte behöva upptäcka det igen.