Engadir unha segunda subrede a unha VPN de sitio a sitio: dous camiños
Os túneles baseados en políticas necesitan selectores coincidentes nos dous extremos; os baseados en rutas, unha ruta. Escolla o camiño correcto e arranxe primeiro a ruta de volta.
Engadir unha segunda subrede a un túnel de sitio a sitio que funciona leva cinco minutos nun deseño e case toda a tarde no outro. Cando o túnel instala rutas para os prefixos que nomea, engade unha ruta e o tráfico séguena. Cando negocia un par fixo de selectores, o prefixo novo queda sen protección ata que ambos extremos acordan un par coincidente. Tres cousas deciden o caso: que describe realmente a configuración de cada extremo, se o tráfico negociado se estreita ao par coincidente máis pequeno e quen é dono da ruta de volta do novo rango.
Lea o núcleo, non a etiqueta de estado
Un túnel que informa de conexión instalou polo menos unha asociación filla, pero non necesariamente a que vostede cre. En Linux o núcleo mostra o que se aplica: ip xfrm policy lista os pares de selectores e swanctl --list-sas (ou o antigo ipsec statusall) mostra o que negociaron os extremos, incluídos os selectores de tráfico en cada dirección. Se o prefixo novo non aparece en ningún, está sen protección diga o que diga o ficheiro de configuración.
Compáreo coa táboa de rutas. Nun deseño baseado en rutas o dispositivo do túnel é o seguinte salto dos prefixos protexidos. Un deseño baseado en políticas adoita non ter ruta específica para a subrede remota, só a ruta por defecto, porque a política escolle o tráfico e non a táboa.
Túneles baseados en políticas: ambos extremos deben listar o prefixo novo
En termos de strongSwan o selector vive en local_ts e remote_ts dentro da configuración filla, sucesores de leftsubnet e rightsubnet. O prefixo novo debe aparecer nos dous extremos en espello: o que o sitio A chama local, o sitio B chámao remoto. Unha discrepancia raramente dá un erro limpo. Os extremos estreitanse á intersección, o prefixo antigo segue funcionando e só o novo falla en silencio.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyEn pfSense ou OPNsense iso significa unha segunda entrada Phase 2 que empareja a nova subrede local coa nova remota e logo aplicar. Conserve a entrada antiga; substituíla move a subrede orixinal en lugar de engadila. Se unha Phase 2 existente xa cobre unha superrede como 0.0.0.0/0 ou un rango resumido, non engada unha entrada máis estreita ao lado: os selectores solapados instalan políticas competidoras e a orde de avaliación decide cal gaña.
IKEv1 fai que cada par de subredes sexa a súa propia Phase 2, e un extremo que acepta un par por intercambio descarta o resto. IKEv2 pode levar varios pares de selectores nunha filla, pero só se ambas implementacións os aceptan. A lista de swanctl --list-sas é a verdade; o que escribiu é unha petición.
Túneles baseados en rutas: a ruta é a política
Unha interface XFRM ou un dispositivo VTI leva o tráfico segundo a táboa de rutas. Apunte o prefixo novo ao dispositivo nos dous sitios e aplícase o estado ligado á transformación da interface. Non hai par de selectores que sincronizar, por iso este deseño escala mellor cando se multiplican as subredes. A guía de reenvío de strongSwan detalla o lado do núcleo.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard leva a idea máis lonxe. AllowedIPs é á vez a lista branca criptográfica e, mediante wg-quick, a entrada da táboa de rutas. Engada o prefixo só nun extremo e obterá un apretón de mans, paquetes saíntes e silencio, porque o outro lado descarta os paquetes cuxa orixe non está na súa lista. A forma wg set substitúe toda a lista, así que repita os prefixos que xa funcionaban ou cortaraos:
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 wg0Ese segundo comando non é opcional cando usou wg set en lugar de wg-quick. O núcleo acepta a lista nova de inmediato, pero nada engade unha ruta para ela, así que o tráfico xerado localmente segue saíndo pola pasarela por defecto. É a razón máis común de que unha subrede WireGuard nova funcione desde o host do túnel e non desde un portátil.
A ruta de volta falla máis a miúdo que o túnel
Os hosts da nova subrede remota deben enviar as respostas pola pasarela VPN. Cando esa pasarela non é o seu router por defecto, a resposta vai ao router da LAN, que a descarta ou a reenvía a internet cun enderezo de orixe privado. Probe desde un host do lado remoto e non desde a pasarela: ip route get 10.30.20.15 en Linux ou Find-NetRoute -RemoteIPAddress 10.30.20.15 en PowerShell mostra o seguinte salto que o host usará de verdade. Se a resposta non é o extremo do túnel, engada alí unha ruta estática para o prefixo novo.
O NAT de orixe no sitio que carece da ruta de volta é unha alternativa lexítima e a forma en que moitos despregamentos hub-and-spoke evitan tocar cada servidor. Aplíqueo tamén ao prefixo novo na pasarela do lado de destino:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEO custo é real. Os rexistros remotos deixan de mostrar enderezos de orixe individuais e as regras de devasa ligadas á subrede orixinal colapsan nunha soa regra para a pasarela. Escóllao a propósito, non porque faltase unha ruta.
As devasas son a outra metade da ruta de volta. Os dispositivos por zonas non estenden automaticamente a zona dunha interface de túnel existente a unha subrede nova, e unha regra escrita para o prefixo antigo non coincidirá. Engada a subrede nova á zona ou ao par de regras nos dous sentidos antes de culpar a IPsec.
Decida con tres preguntas e verifique co tráfico
A versión rápida: a configuración do extremo nomea prefixos (baseada en políticas) ou o tráfico encamiñase a unha interface (baseada en rutas)? Listan ambos extremos o prefixo novo? Hai un camiño de volta desde a subrede nova ao rango de orixe orixinal?
| 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 |
A verificación é onde a maioría dos cambios se pechan demasiado cedo. Un ping desde a pasarela proba pouco, porque a pasarela envía desde si mesma e a miúdo coincide cunha política distinta á dun host. Faga ping desde un host da subrede nova, logo execute a aplicación que motivou o cambio e mire contadores, non unha icona de estado.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showNun túnel baseado en políticas os contadores de ip xfrm state deben subir nos dous sentidos; contadores planos significan que o paquete se encamiña pero non se selecciona. En WireGuard, wg show informa da transferencia por extremo, e un apretón de mans con cero bytes recibidos apunta á lista do lado remoto ou á súa ruta de volta.
Remate rexistrando o prefixo, o selector ou a ruta do extremo, a decisión sobre a ruta de volta e a entrada da devasa xunto co resto do inventario do túnel. Despois reinicie unha pasarela e probe outra vez: unha ruta engadida á man desaparece e a seguinte persoa non debería ter que redescubrilo.