Afegir una segona subxarxa a una VPN de lloc a lloc: dos camins
Els túnels basats en polítiques necessiten selectors coincidents als dos extrems; els basats en rutes, una ruta. Trieu el camí correcte i arregleu primer la ruta de tornada.
Afegir una segona subxarxa a un túnel de lloc a lloc que funciona triga cinc minuts amb un disseny i gairebé tota la tarda amb l’altre. Quan el túnel instal·la rutes per als prefixos que anomeneu, afegiu una ruta i el trànsit la segueix. Quan negocia un parell de selectors fix, el prefix nou queda sense protecció fins que els dos extrems acorden un parell coincident. Tres coses decideixen el cas: què descriu realment la configuració de cada extrem, si el trànsit negociat s’estreny al parell coincident més petit i qui posseeix la ruta de tornada per al nou rang.
Llegiu el nucli, no l’etiqueta d’estat
Un túnel que informa de connexió ha instal·lat com a mínim una associació filla, però no necessàriament la que penseu. A Linux el nucli mostra què s’aplica: ip xfrm policy llista els parells de selectors i swanctl --list-sas (o el més antic ipsec statusall) mostra què han negociat els extrems, incloent-hi els selectors de trànsit en cada direcció. Si el prefix nou no apareix en cap dels dos, no està protegit, digui el que digui el fitxer de configuració.
Compareu-ho amb la taula de rutes. En una configuració basada en rutes, el dispositiu del túnel és el següent salt per als prefixos protegits. Una configuració basada en polítiques sovint no té cap ruta específica per a la subxarxa remota, només la ruta per defecte, perquè la política tria el trànsit i no la taula.
Túnels basats en polítiques: els dos extrems han de llistar el prefix nou
En terminologia strongSwan el selector viu a local_ts i remote_ts dins la configuració filla, els successors de leftsubnet i rightsubnet. El prefix nou ha d’aparèixer als dos extrems mirallat: el que el lloc A anomena local, el lloc B l’anomena remot. Una discrepància rares vegades dona un error net. Els extrems s’estrenyen a la intersecció, el prefix antic continua funcionant i el nou falla en silenci.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyA pfSense o OPNsense això vol dir una segona entrada Phase 2 que emparellla la subxarxa local nova amb la remota nova, i després aplicar. Manteniu l’entrada antiga; substituir-la mou la subxarxa original en lloc d’afegir-hi. Si una Phase 2 existent ja cobreix una superxarxa com 0.0.0.0/0 o un rang resumit, no afegiu una entrada més estreta al costat: els selectors solapats instal·len polítiques competidores i l’ordre d’avaluació decideix qui guanya.
IKEv1 fa que cada parell de subxarxes sigui la seva pròpia Phase 2, i un extrem que accepta un parell per intercanvi descarta la resta. IKEv2 pot portar diversos parells de selectors en una filla, però només si les dues implementacions els accepten. La llista de swanctl --list-sas és la veritat; el que heu escrit és una petició.
Túnels basats en rutes: la ruta és la política
Una interfície XFRM o un dispositiu VTI porta el trànsit segons la taula de rutes. Adreceu el prefix nou al dispositiu als dos llocs i s’aplica l’estat lligat a la transformació de la interfície. No hi ha cap parell de selectors per sincronitzar, per això aquest disseny escala millor quan es multipliquen les subxarxes. La guia de reenviament de strongSwan detalla el costat del nucli.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard porta la idea més enllà. AllowedIPs és alhora la llista blanca criptogràfica i, mitjançant wg-quick, l’entrada de la taula de rutes. Afegiu el prefix només en un extrem i tindreu un handshake, paquets de sortida i silenci, perquè l’altre costat descarta els paquets la font dels quals no és a la seva llista. La forma wg set substitueix tota la llista, així que repetiu els prefixos que ja funcionaven o els tallareu:
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 wg0Aquesta segona ordre no és opcional quan heu fet servir wg set en lloc de wg-quick. El nucli accepta la llista nova de seguida, però res no hi afegeix una ruta, així que el trànsit generat localment continua sortint per la porta d’enllaç per defecte. És la raó més habitual que una subxarxa WireGuard nova funcioni des de l’amfitrió del túnel i no des d’un portàtil.
La ruta de tornada falla més sovint que el túnel
Els amfitrions de la subxarxa remota nova han d’enviar les respostes per la porta d’enllaç de la VPN. Quan aquesta porta no és el seu encaminador per defecte, la resposta va a l’encaminador de la LAN, que o la descarta o la reenvia a internet amb una adreça d’origen privada. Proveu-ho des d’un amfitrió de l’altre costat i no des de la porta: ip route get 10.30.20.15 a Linux o Find-NetRoute -RemoteIPAddress 10.30.20.15 a PowerShell mostra el següent salt que l’amfitrió farà servir de veritat. Si la resposta no és el punt final del túnel, afegiu-hi una ruta estàtica per al prefix nou.
El NAT d’origen al lloc que no té la ruta de tornada és una alternativa legítima i és com moltes implantacions hub-and-spoke eviten tocar cada servidor. Apliqueu-lo també al prefix nou a la porta del costat de destí:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEEl cost és real. Els registres remots deixen de mostrar adreces d’origen individuals i les regles de tallafoc lligades a la subxarxa original es col·lapsen en una sola regla per a la porta. Trieu-ho deliberadament i no perquè faltava una ruta.
Els tallafocs són l’altra meitat de la ruta de tornada. Els dispositius per zones no estenen automàticament la zona d’una interfície de túnel existent a una subxarxa nova, i una regla escrita per al prefix antic no coincidirà. Afegiu la subxarxa nova a la zona o al parell de regles en tots dos sentits abans de culpar IPsec.
Decidiu amb tres preguntes i verifiqueu amb trànsit
La versió ràpida: la configuració de l’extrem anomena prefixos (basada en polítiques) o el trànsit s’encamina cap a una interfície (basada en rutes)? Els dos caps llisten el prefix nou? Hi ha un camí de tornada de la subxarxa nova al rang d’origen original?
| 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 |
La verificació és on la majoria de canvis es tanquen massa aviat. Un ping des de la porta demostra poc, perquè la porta envia des de si mateixa i sovint coincideix amb una política diferent de la d’un amfitrió. Feu ping des d’un amfitrió de la subxarxa nova, després executeu l’aplicació que va motivar el canvi i mireu els comptadors, no una icona d’estat.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showEn un túnel basat en polítiques els comptadors de ip xfrm state han de pujar en tots dos sentits; comptadors plans volen dir que el paquet s’encamina però no se selecciona. A WireGuard, wg show informa de la transferència per extrem, i un handshake amb zero bytes rebuts assenyala la llista blanca de l’altre costat o la seva ruta de tornada.
Acabeu registrant el prefix, el selector o la ruta de l’extrem, la decisió sobre la ruta de tornada i l’entrada del tallafoc amb la resta de l’inventari del túnel. Després reinicieu una porta d’enllaç i torneu a provar: una ruta afegida a mà desapareix i la propera persona no hauria de tornar a descobrir-ho.