Jak poslat VPN jen jednu privátní podsíť

Jedna privátní podsíť tunelem a vše ostatní vaší obvyklou cestou je malý požadavek s velkým počtem způsobů, jak to udělat špatně. Výsledek nerozhoduje zaškrtávací pole s nápisem split tunneling, ale to, kde se rozhodnutí vynucuje: vlastní směrovací tabulka klienta, cesta, kterou server posílá, nebo politika, kterou si obě strany vyjednají. Zvolte špatnou vrstvu a dostanete buď plný tunel, který jste nikdy nechtěli, nebo cestu do tunelu, který druhá strana odmítá přijmout. Než otevřu jakoukoli konfiguraci, použiju zkoušku se třemi podmínkami, a pak vyberu jeden z mechanismů níže.

Tři podmínky, které rozhodují návrh

Za prvé potřebujete přesný prefix a masku od správce sítě. Síť 10.x není prefix; 10.20.0.0/16 je. Ověřte, že se nepřekrývá s vaší domácí LAN, s Docker bridge ani s jinou VPN, kterou provozujete, protože překryv dělá cestu nejednoznačnou a jádro vybere záznam, který jste nezamýšleli.

Za druhé, kdo odpovídá na zpětný provoz. Směrování paketu do tunelu ho dostane jen na VPN server. Pokud podsíť leží za jiným routerem, který nemá cestu zpět do vašeho poolu klientů, server musí provoz maskovat, nebo se ten router musí váš pool naučit. Žádná cesta na straně klienta neopraví chybějící zpětnou cestu.

Za třetí, místo vynucení. Někteří klienti nainstalují cestu a zbytek udělá operační systém. Jiní vyjednávají politiku, a politika, kterou brána nepřijme, nevytvoří vůbec žádný tunel: pakety se zahazují bez zjevné chyby. Zjistěte, který z těch dvou případů je váš, než něco napíšete.

WireGuard: AllowedIPs je směrovací tabulka

Na klientovi AllowedIPs vypisuje cíle, které smějí vstoupit do tunelu, a wg-quick mění každý záznam na obyčejnou cestu. Klientská polovina tohoto úkolu je tedy jeden řádek.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Teď porovnejte záznam serveru pro stejného klienta. Popisuje, co server pošle klientovi, což je obvykle adresa tunelu klienta, ne privátní podsíť.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Prohození těchto dvou je chyba, kterou vidím nejčastěji. Když dáte 10.20.0.0/16 do sekce peer na serveru, tvrdíte, že celá podsíť leží za tímto klientem, což je nárok site-to-site, ne povolení. Pakety, které neodpovídají AllowedIPs žádného peer, se tiše zahazují, takže špatný záznam vypadá přesně jako problém s firewallem.

Pokud cesty spravujete sami, nastavte Table = off pod [Interface] a přidejte cestu, kterou chcete. Pak se nic nepřidává automaticky, takže cesta patří do toho, co rozhraní zvedá.

OpenVPN: pošlete cestu a pak se ujistěte, že dorazila

Na běžném serveru je změna jedna direktiva v konfiguraci serveru, vedle poolu klientů.

push "route 10.20.0.0 255.255.0.0"

Klient ji přidá při připojení. Režim selhání se objeví, když stejný profil posílá i redirect-gateway, nebo když už někdo přidal route-nopull: první změní relaci na plný tunel a druhé zahodí každou poslanou cestu včetně vaší.

Klient, který potřebuje úzké chování vůči serveru s plným tunelem, má ignorovat jen ty části, které nechce. V OpenVPN 2.4 a novějším existuje pull-filter přesně pro to.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Držte adresní rodiny oddělené: poslaná cesta IPv4 neudělá nic pro interní službu, která se překládá na IPv6, a ta služba selhává přes tunel, zatímco všechno ostatní vypadá v pořádku.

Když privátní podsíť není na VPN serveru, ale za jiným klientem, server to musí vědět. Přidejte soubor pro každého klienta přes client-config-dir obsahující iroute 10.20.0.0 255.255.0.0, plus odpovídající route, aby se ostatní klienti cestu naučili. Bez iroute nemá server důvod posílat tento prefix právě tímto tunelem.

IPsec: selektory provozu se musí shodnout

U IPsec není žádná cesta k odeslání. Obě strany vyjednají, které adresy žijí uvnitř tunelu, a provoz mimo dohodnuté selektory se ani nešifruje, ani neposílá skrz. Na klientovi strongSwan jsou selektory výslovné.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Je-li brána nakonfigurována s 0.0.0.0/0 na obou stranách, zúžení IKEv2 obvykle zredukuje podřízenou SA na průnik obou návrhů, což je výsledek, který chcete. Některé brány místo toho odmítnou návrh, který neodpovídá jejich nakonfigurovaným selektorům, a log pak ukáže selhanou podřízenou SA, ne stížnost na směrování. Když se to stane, změna patří na bránu, protože cesta na klientovi nemůže vytvořit tunel pro selektor, který druhá strana nepřijme.

Ve Windows vestavěný klient skrývá stejné rozhodnutí za dvěma nastaveními. Rozdělení tunelu musí být zapnuté a prefix musí být zaregistrovaný u profilu.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Právě registrace prefixu mu umožní přežít opětovné připojení, což cesta přidaná ručně nedokáže.

Držte koncový bod a DNS mimo rozhodnutí

Koncový bod VPN musí zůstat dostupný bez tunelu, jinak se tunel zhroutí do sebe. Když se směruje jen 10.20.0.0/16, je to automatické, protože koncový bod je veřejná adresa. U profilu plného tunelu to neplatí a klient potřebuje výslovnou cestu k hostiteli koncového bodu, než se tunel zvedne.

DNS je druhé rozhodnutí, které za vás poslání cesty neudělá. Interní názvy se obvykle překládají přes resolver, kam se dostane jen privátní síť. Pokud server posílá DNS server, jde každý název přes něj; pokud ne, interní názvy buď selhávají, nebo se veřejně přeloží na něco, co jste nezamýšleli. Rozdělené DNS drží jednu vyhledávací doménu na interním resolveru, ale závisí na podpoře klienta, takže to berte jako samostatný úkol, ne jako vedlejší efekt směrování.

Ověřte, pak restartujte a ověřte znovu

Tři sondy pokrývají otázku směrování. Zeptejte se jádra, kam by šla vzdálená adresa, stáhněte něco zevnitř podsítě a pak potvrďte, že běžný veřejný požadavek stále vychází vaším normálním připojením.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

První řádek pojmenuje rozhraní. Pokud pojmenuje vaše fyzické rozhraní, cesta nikdy nedorazila. Ve Windows odpovídá na stejnou otázku Find-NetRoute -RemoteIPAddress 10.20.5.7 a poslední sonda má stále ukazovat vaši obvyklou adresu, ne adresu VPN serveru.

Pak restartujte. Cesty přidané ručně zmizí, zatímco cesty z profilu, z poslané konfigurace nebo z AllowedIPs se vrátí. Pokud úzký přístup funguje před restartem a po něm selže, chyba je v tom, jak tunel startuje, ne v samotné cestě.

Než to prohlásíte za hotové, potvrďte čtyři věci: prefix přišel od správce sítě a nepřekrývá nic lokálního, zpětná cesta existuje nebo ji nahrazuje pravidlo maskování, mechanismus, který jste nastavili, je ten, který na vaší platformě vynucuje směrování, a stejné sondy projdou i po čistém restartu. poznámky strongSwan k forwarding stojí za přečtení, pokud je zpětná cesta tou částí, která stále selhává.