Přidání druhé podsítě do VPN mezi lokalitami: dvě cesty
Tunely založené na zásadách potřebují shodné selektory na obou stranách; tunely založené na trasách potřebují trasu. Zvolte správnou cestu a nejprve opravte zpáteční trasu.
Přidání druhé podsítě do funkčního tunelu mezi lokalitami zabere u jednoho návrhu pět minut a u druhého skoro celé odpoledne. Když tunel instaluje trasy pro zadané prefixy, přidáte trasu a provoz ji následuje. Když vyjednává jeden pevný pár selektorů, nový prefix zůstává nechráněný, dokud se obě strany nedohodnou na shodném páru. O případu rozhodují tři věci: co konfigurace každé strany skutečně popisuje, zda se vyjednaný provoz zužuje na nejmenší shodný pár a kdo vlastní zpáteční cestu pro nový rozsah.
Čtěte jádro, ne štítek stavu
Tunel, který hlásí připojení, nainstaloval alespoň jednu podřízenou asociaci, ne nutně tu, kterou čekáte. V Linuxu jádro ukazuje, co se uplatňuje: ip xfrm policy vypisuje páry selektorů a swanctl --list-sas (nebo starší ipsec statusall) ukazuje, co strany vyjednaly, včetně selektorů provozu v obou směrech. Pokud nový prefix není v ani jednom, je nechráněný, ať konfigurační soubor říká cokoli.
Porovnejte to s routovací tabulkou. U návrhu založeného na trasách je zařízení tunelu dalším skokem pro chráněné prefixy. Návrh založený na zásadách často nemá konkrétní trasu pro vzdálenou podsíť, jen výchozí trasu, protože provoz vybírá zásada, ne tabulka.
Tunely založené na zásadách: obě strany musí uvést nový prefix
V terminologii strongSwan žije selektor v local_ts a remote_ts v podřízené konfiguraci, nástupcích leftsubnet a rightsubnet. Nový prefix se musí objevit na obou stranách zrcadlově: co lokalita A nazývá místním, lokalita B nazývá vzdáleným. Nesoulad málokdy dá čistou chybu. Strany se zúží na průnik, starý prefix dál funguje a nový tiše selže.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyNa pfSense nebo OPNsense to znamená druhý záznam Phase 2 spojující novou místní podsíť s novou vzdálenou a poté použití. Ponechte starý záznam; nahrazení přesune původní podsíť místo přidání. Pokud existující Phase 2 už pokrývá supernet jako 0.0.0.0/0 nebo shrnutý rozsah, nepřidávejte vedle užší záznam: překrývající se selektory instalují konkurenční zásady a o vítězi rozhodne pořadí vyhodnocení.
IKEv1 dělá z každého páru podsítí vlastní Phase 2 a strana, která bere jeden pár na výměnu, zbytek zahodí. IKEv2 unese několik párů selektorů v jedné podřízené asociaci, ale jen když je obě implementace přijmou. Seznam z swanctl --list-sas je pravda; co jste napsali, je žádost.
Tunely založené na trasách: trasou je zásada
Rozhraní XFRM nebo zařízení VTI nese provoz podle routovací tabulky. Nasměrujete nový prefix na zařízení v obou lokalitách a uplatní se stav vázaný na transformaci rozhraní. Není žádný pár selektorů k synchronizaci, proto tento návrh lépe škáluje s přibývajícími podsítěmi. Průvodce předáváním strongSwan rozebírá stranu jádra podrobněji.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard jde dál. AllowedIPs je zároveň kryptografický seznam povolených a přes wg-quick i záznam v routovací tabulce. Přidejte prefix jen na jedné straně a získáte handshake, odchozí pakety a ticho, protože vzdálená strana zahazuje pakety, jejichž zdroj není v jejím seznamu. Forma wg set nahrazuje celý seznam, proto znovu uveďte prefixy, které už fungovaly, jinak je odříznete:
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ý příkaz není volitelný, když jste použili wg set místo wg-quick. Jádro nový seznam povolených přijme hned, ale nic k němu nepřidá trasu, takže lokálně vytvořený provoz stále odchází přes výchozí bránu. To je nejčastější důvod, proč nová podsíť WireGuard funguje z hostitele tunelu a ne z notebooku.
Zpáteční cesta selhává častěji než tunel
Hostitelé v nové vzdálené podsíti musí posílat odpovědi zpět přes VPN bránu. Když tato brána není jejich výchozím routerem, odpověď jde na LAN router, který ji zahodí nebo přepošle do internetu se soukromou zdrojovou adresou. Testujte z hostitele na vzdálené straně, ne z brány: ip route get 10.30.20.15 v Linuxu nebo Find-NetRoute -RemoteIPAddress 10.30.20.15 v PowerShellu ukáže další skok, který hostitel skutečně použije. Pokud odpověď není koncovým bodem tunelu, přidejte tam statickou trasu pro nový prefix.
Zdrojový NAT v lokalitě, které chybí zpáteční trasa, je legitimní alternativa a způsob, jak se mnohá nasazení hub-and-spoke vyhýbají zásahu do každého serveru. Použijte ho i na nový prefix na bráně na straně cíle:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADECena je reálná. Vzdálené protokoly přestanou ukazovat jednotlivé zdrojové adresy a pravidla firewallu vázaná na původní podsíť se slijí v jedno pravidlo pro bránu. Zvolte to vědomě, ne proto, že chyběla trasa.
Firewally jsou druhá polovina zpáteční cesty. Zařízení založená na zónách nerozšiřují zónu existujícího tunelového rozhraní na novou podsíť automaticky a pravidlo psané pro starý prefix nebude odpovídat. Přidejte novou podsíť do zóny nebo do páru pravidel v obou směrech, než obviníte IPsec.
Rozhodněte třemi otázkami, pak ověřte provozem
Rychlá verze: uvádí konfigurace strany prefixy (založené na zásadách), nebo se provoz routuje do rozhraní (založené na trasách)? Uvádějí oba konce nový prefix? Existuje cesta zpět z nové podsítě do původního rozsahu zdrojů?
| 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 |
Ověření je místo, kde se většina změn zavírá příliš brzy. Ping z brány dokazuje málo, protože brána vysílá sama ze sebe a často odpovídá jiné zásadě než hostitel. Pingněte z hostitele v nové podsíti, pak spusťte aplikaci, která změnu vyvolala, a sledujte čítače, ne ikonu stavu.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showU tunelu založeného na zásadách mají čítače ip xfrm state růst v obou směrech; ploché čítače znamenají, že paket je routovaný, ale nevybraný. U WireGuardu wg show ukazuje přenos po stranách a handshake s nulou přijatých bajtů ukazuje na seznam povolených vzdálené strany nebo její zpáteční trasu.
Skončete zapsáním prefixu, selektoru nebo trasy strany, rozhodnutí o zpáteční cestě a záznamu firewallu spolu se zbytkem inventáře tunelu. Pak restartujte jednu bránu a otestujte to znovu: ručně přidaná trasa zmizí a další člověk to nemá objevovat znovu.