Adăugarea unei a doua subrețele la un VPN site-la-site: două căi
Tunelurile bazate pe politici au nevoie de selectori potriviți pe ambele părți; cele bazate pe rute au nevoie de o rută. Alegeți calea corectă și reparați mai întâi ruta de retur.
Adăugarea unei a doua subrețele la un tunel site-la-site funcțional durează cinci minute într-un proiect și aproape toată după-amiaza în celălalt. Când tunelul instalează rute pentru prefixele pe care le numiți, adăugați o rută și traficul o urmează. Când negociază o singură pereche fixă de selectori, noul prefix rămâne neprotejat până când ambele părți cad de acord asupra unei perechi potrivite. Trei lucruri decid: ce descrie de fapt configurația fiecărei părți, dacă traficul negociat se îngustează la cea mai mică pereche potrivită și cine deține ruta de retur pentru noul interval.
Citiți nucleul, nu eticheta de stare
Un tunel care raportează conexiune a instalat cel puțin o asociere copil, dar nu neapărat pe cea la care vă gândiți. În Linux nucleul arată ce se aplică: ip xfrm policy listează perechile de selectori, iar swanctl --list-sas (sau vechiul ipsec statusall) arată ce au negociat părțile, inclusiv selectorii de trafic pe fiecare direcție. Dacă noul prefix nu apare în niciunul, este neprotejat, orice ar spune fișierul de configurare.
Comparați cu tabela de rutare. Într-un aranjament bazat pe rute, dispozitivul tunelului este următorul salt pentru prefixele protejate. Un aranjament bazat pe politici nu are adesea o rută specifică pentru subrețeaua îndepărtată, doar ruta implicită, pentru că politica alege traficul, nu tabela.
Bazat pe politici: ambele părți trebuie să listeze noul prefix
În termenii strongSwan selectorul stă în local_ts și remote_ts în configurația copil, succesorii lui leftsubnet și rightsubnet. Noul prefix trebuie să apară pe ambele părți în oglindă: ce situl A numește local, situl B numește la distanță. Neconcordanța dă rareori o eroare curată. Părțile se îngustează la intersecție, prefixul vechi continuă să funcționeze și doar cel nou eșuează în tăcere.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyÎn pfSense sau OPNsense asta înseamnă o a doua intrare Phase 2 care împerechează noua subrețea locală cu cea îndepărtată nouă, apoi aplicare. Păstrați intrarea veche; înlocuirea mută subrețeaua originală în loc să o adauge. Dacă o Phase 2 existentă acoperă deja o superrețea ca 0.0.0.0/0 sau un interval sumarizat, nu adăugați o intrare mai îngustă alături: selectorii suprapuși instalează politici concurente, iar ordinea de evaluare decide câștigătorul.
IKEv1 face din fiecare pereche de subrețele propriul Phase 2, iar o parte care acceptă o pereche pe schimb aruncă restul. IKEv2 poate transporta mai multe perechi de selectori într-un copil, dar numai dacă ambele implementări le acceptă. Lista din swanctl --list-sas este adevărul; ce ați tastat este o cerere.
Bazat pe rute: ruta este politica
O interfață XFRM sau un dispozitiv VTI transportă trafic conform tabelei de rutare. Îndreptați noul prefix către dispozitiv pe ambele situri, iar starea legată de transformarea interfeței se aplică. Nu există pereche de selectori de sincronizat, de aceea acest proiect scalează mai bine pe măsură ce subrețelele se înmulțesc. Ghidul strongSwan de forwarding detaliază partea de nucleu.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard duce ideea mai departe. AllowedIPs este simultan lista de permisiuni criptografice și, prin wg-quick, intrarea din tabela de rutare. Adăugați prefixul doar pe o parte și obțineți un handshake, pachete de ieșire și tăcere, pentru că partea îndepărtată aruncă pachetele a căror sursă nu este pe lista ei. Forma wg set înlocuiește toată lista, așa că reluați prefixele care funcționau deja, altfel le veți tăia:
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 wg0A doua comandă nu este opțională când ați folosit wg set în loc de wg-quick. Nucleul acceptă imediat lista nouă, dar nimic nu adaugă o rută pentru ea, așa că traficul generat local iese în continuare prin poarta implicită. Este motivul cel mai frecvent pentru care o subrețea WireGuard nouă funcționează de pe hostul tunelului și nu de pe un laptop.
Ruta de retur eșuează mai des decât tunelul
Hosturile din noua subrețea îndepărtată trebuie să trimită răspunsurile înapoi prin poarta VPN. Când acea poartă nu este routerul lor implicit, răspunsul merge la routerul LAN, care îl aruncă sau îl trimite mai departe pe internet cu o adresă sursă privată. Testați de pe un host din partea îndepărtată, nu de pe poartă: ip route get 10.30.20.15 în Linux sau Find-NetRoute -RemoteIPAddress 10.30.20.15 în PowerShell arată următorul salt pe care hostul îl folosește cu adevărat. Dacă răspunsul nu este punctul final al tunelului, adăugați acolo o rută statică pentru noul prefix.
NAT-ul de sursă pe situl care nu are ruta de retur este o alternativă legitimă și modul în care multe implementări hub-and-spoke evită să atingă fiecare server. Aplicați-l și noului prefix pe poarta din partea destinației:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADECostul este real. Jurnalele îndepărtate nu mai arată adrese sursă individuale, iar regulile de firewall bazate pe subrețeaua originală se contopesc într-o singură regulă pentru poartă. Alegeți asta deliberat, nu pentru că lipsea o rută.
Firewall-urile sunt cealaltă jumătate a rutei de retur. Dispozitivele pe zone nu extind automat zona unei interfețe de tunel existente la o subrețea nouă, iar o regulă scrisă pentru prefixul vechi nu se va potrivi. Adăugați noua subrețea în zonă sau în perechea de reguli în ambele sensuri înainte de a da vina pe IPsec.
Decideți cu trei întrebări, apoi verificați cu trafic
Varianta scurtă: configurația părții numește prefixe (bazată pe politici) sau traficul este rutat într-o interfață (bazată pe rute)? Ambele capete listează noul prefix? Există un drum înapoi de la noua subrețea la intervalul sursă 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 |
Verificarea este locul unde majoritatea modificărilor se închid prea devreme. Un ping de pe poartă dovedește puțin, pentru că poarta trimite de la sine și adesea corespunde unei politici diferite de cea a unui host. Faceți ping de pe un host din noua subrețea, apoi rulați aplicația care a motivat schimbarea și urmăriți contoarele, nu o pictogramă de stare.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showPe un tunel bazat pe politici contoarele ip xfrm state trebuie să crească în ambele sensuri; contoarele plate înseamnă că pachetul este rutat, dar nu selectat. Pe WireGuard wg show raportează transferul pe parte, iar un handshake cu zero octeți primiți indică lista părții îndepărtate sau ruta ei de retur.
Încheiați înregistrând prefixul, selectorul sau ruta părții, decizia privind ruta de retur și intrarea de firewall împreună cu restul inventarului tunelului. Apoi reporniți o poartă și testați din nou: o rută adăugată manual dispare, iar următoarea persoană nu ar trebui să redescopere asta.