Pridanie druhej podsiete do VPN medzi lokalitami: dve cesty
Tunely založené na pravidlách potrebujú zhodné selektory na oboch stranách; tunely založené na trasách potrebujú trasu. Vyberte správnu cestu a najprv opravte spätnú trasu.
Pridanie druhej podsiete do funkčného tunela medzi lokalitami trvá v jednom návrhu päť minút a v druhom takmer celé popoludnie. Keď tunel inštaluje trasy pre zadané prefixy, pridáte trasu a prevádzka ju nasleduje. Keď vyjednáva jeden pevný pár selektorov, nový prefix zostáva nechránený, kým sa obe strany nedohodnú na zhodnom páre. Rozhodujú tri veci: čo konfigurácia každej strany naozaj opisuje, či sa vyjednaná prevádzka zúži na najmenší zhodný pár a komu patrí spätná cesta pre nový rozsah.
Čítajte jadro, nie štítok stavu
Tunel, ktorý hlási spojenie, nainštaloval aspoň jednu podriadenú asociáciu, ale nie nutne tú, ktorú čakáte. V Linuxe jadro ukazuje, čo sa uplatňuje: ip xfrm policy vypisuje páry selektorov a swanctl --list-sas (alebo starší ipsec statusall) ukazuje, čo strany vyjednali, vrátane selektorov prevádzky v oboch smeroch. Ak nový prefix nie je v ani jednom, je nechránený, nech konfiguračný súbor hovorí čokoľvek.
Porovnajte to s tabuľkou trás. V návrhu založenom na trasách je zariadenie tunela ďalším skokom pre chránené prefixy. Návrh založený na pravidlách často nemá konkrétnu trasu pre vzdialenú podsieť, iba predvolenú trasu, pretože prevádzku vyberá pravidlo, nie tabuľka.
Založené na pravidlách: obe strany musia uviesť nový prefix
V terminológii strongSwan selektor žije v local_ts a remote_ts v podriadenej konfigurácii, nástupcoch leftsubnet a rightsubnet. Nový prefix sa musí objaviť na oboch stranách zrkadlovo: čo lokalita A nazýva lokálnym, lokalita B nazýva vzdialeným. Nezhoda málokedy dá čistú chybu. Strany sa zúžia na prienik, starý prefix funguje ďalej a iba nový ticho zlyhá.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyNa pfSense alebo OPNsense to znamená druhý záznam Phase 2 spájajúci novú lokálnu podsieť s novou vzdialenou, a potom použitie. Ponechajte starý záznam; nahradenie presunie pôvodnú podsieť namiesto pridania. Ak existujúci Phase 2 už pokrýva supernet ako 0.0.0.0/0 alebo zhrnutý rozsah, nepridávajte vedľa užší záznam: prekrývajúce sa selektory inštalujú konkurujúce pravidlá a o víťazovi rozhoduje poradie vyhodnotenia.
IKEv1 robí z každého páru podsietí vlastný Phase 2 a strana, ktorá berie jeden pár na výmenu, zvyšok zahodí. IKEv2 unesie niekoľko párov selektorov v jednej podriadenej asociácii, ale len ak ich obe implementácie prijmú. Zoznam z swanctl --list-sas je pravda; to, čo ste napísali, je žiadosť.
Založené na trasách: trasou je pravidlo
Rozhranie XFRM alebo zariadenie VTI nesie prevádzku podľa tabuľky trás. Nasmerujete nový prefix na zariadenie v oboch lokalitách a uplatní sa stav viazaný na transformáciu rozhrania. Nie je žiadny pár selektorov na synchronizáciu, preto tento návrh lepšie škáluje s pribúdajúcimi podsieťami. Príručka strongSwan k preposielaniu rozoberá stranu jadra podrobnejšie.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard ide ďalej. AllowedIPs je zároveň kryptografický zoznam povolených a cez wg-quick aj záznam v tabuľke trás. Pridajte prefix len na jednej strane a získate podanie ruky, odchádzajúce pakety a ticho, pretože vzdialená strana zahadzuje pakety, ktorých zdroj nie je na jej zozname. Forma wg set nahrádza celý zoznam, preto zopakujte prefixy, ktoré už fungovali, inak ich odrežete:
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 wg0Druhý príkaz nie je voliteľný, keď ste použili wg set namiesto wg-quick. Jadro prijme nový zoznam hneď, ale nič k nemu nepridá trasu, takže lokálne vytvorená prevádzka stále odchádza cez predvolenú bránu. To je najčastejší dôvod, prečo nová podsieť WireGuard funguje z hostiteľa tunela a nie z notebooku.
Spätná cesta zlyháva častejšie ako tunel
Hostitelia v novej vzdialenej podsieti musia posielať odpovede späť cez VPN bránu. Keď tá brána nie je ich predvoleným smerovačom, odpoveď ide na LAN smerovač, ktorý ju zahodí alebo prepošle do internetu so súkromnou zdrojovou adresou. Testujte z hostiteľa na vzdialenej strane, nie z brány: ip route get 10.30.20.15 v Linuxe alebo Find-NetRoute -RemoteIPAddress 10.30.20.15 v PowerShelli ukáže ďalší skok, ktorý hostiteľ naozaj použije. Ak odpoveď nie je koncový bod tunela, pridajte tam statickú trasu pre nový prefix.
Zdrojový NAT v lokalite bez spätnej trasy je legitímna alternatíva a spôsob, akým sa mnohé nasadenia hub-and-spoke vyhýbajú dotyku každého servera. Použite ho aj na nový prefix na bráne na strane cieľa:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADECena je skutočná. Vzdialené záznamy prestanú zobrazovať jednotlivé zdrojové adresy a pravidlá firewallu viazané na pôvodnú podsieť sa zlúčia do jedného pravidla pre bránu. Vyberte to vedome, nie preto, že chýbala trasa.
Firewally sú druhou polovicou spätnej cesty. Zariadenia založené na zónach nerozširujú zónu existujúceho tunelového rozhrania na novú podsieť automaticky a pravidlo napísané pre starý prefix nebude sedieť. Pridajte novú podsieť do zóny alebo do páru pravidiel v oboch smeroch, kým obviníte IPsec.
Rozhodnite tromi otázkami, potom overte prevádzkou
Krátka verzia: uvádza konfigurácia strany prefixy (založené na pravidlách), alebo sa prevádzka smeruje do rozhrania (založené na trasách)? Uvádzajú oba konce nový prefix? Existuje cesta späť z novej podsiete do pôvodného rozsahu zdrojov?
| 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 |
Overenie je miesto, kde sa väčšina zmien uzatvára príliš skoro. Ping z brány dokazuje málo, pretože brána vysiela sama zo seba a často sedí na iné pravidlo ako hostiteľ. Pingnite z hostiteľa v novej podsieti, potom spustite aplikáciu, ktorá zmenu vyvolala, a sledujte počítadlá, nie ikonu stavu.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showNa tuneli založenom na pravidlách majú počítadlá ip xfrm state rásť v oboch smeroch; ploché počítadlá znamenajú, že paket je smerovaný, ale nie vybraný. Na WireGuarde wg show ukazuje prenos po stranách a podanie ruky s nulou prijatých bajtov ukazuje na zoznam vzdialenej strany alebo jej spätnú trasu.
Skončite zápisom prefixu, selektora alebo trasy strany, rozhodnutia o spätnej ceste a záznamu firewallu spolu so zvyškom inventára tunela. Potom reštartujte jednu bránu a otestujte znova: ručne pridaná trasa zmizne a ďalší človek by to nemal znovu objavovať.