Ako cez VPN poslať iba jednu privátnu podsieť

Vyberte medzi cestou na klientovi, cestou, ktorú posiela server, a vyjednanými selektormi, a potom preneste jednu privátnu podsieti bez plného tunela.

Jedna privátna podsieti tunelom a všetko ostatné vašou obvyklou cestou je malá požiadavka s veľkým počtom spôsobov, ako to pokaziť. Výsledok nerozhoduje zaškrtávacie pole s nápisom split tunneling, ale to, kde sa rozhodnutie vynucuje: vo vlastnej smerovacej tabuľke klienta, v ceste, ktorú posiela server, alebo v politike, o ktorej sa dohodnú obe strany. Vyberte nesprávnu vrstvu a dostanete buď plný tunel, ktorý ste nikdy nechceli, alebo cestu do tunela, ktorý druhá strana odmieta prijať. Pred otvorením akejkoľvek konfigurácie používam test s tromi podmienkami a potom vyberiem jeden z mechanizmov nižšie.

Tri podmienky, ktoré rozhodujú o návrhu

Po prvé, potrebujete presný prefix a masku od správcu siete. Sieť 10.x nie je prefix; 10.20.0.0/16 je. Overte, že sa neprekrýva s vašou domácou LAN, Docker mostom ani iným VPN, ktoré prevádzkujete, pretože prekrytie robí cestu nejednoznačnou a jadro vyberie záznam, ktorý ste nemali v úmysle.

Po druhé, kto odpovedá na spätnú premávku. Smerovanie paketu do tunela ho dostane len na VPN server. Ak podsieti leží za iným routerom, ktorý nemá cestu späť do vášho fondu klientov, server musí premávku maskovať, alebo sa ten router musí naučiť váš fond. Žiadna cesta na strane klienta neopraví chýbajúcu spätnú cestu.

Po tretie, miesto vynútenia. Niektorí klienti nainštalujú cestu a zvyšok urobí operačný systém. Iní vyjednávajú politiku, a politika, ktorú brána neprijme, nevytvorí vôbec žiadny tunel: pakety sa zahadzujú bez zjavnej chyby. Zistite, ktorý z tých dvoch prípadov je váš, skôr než čokoľvek napíšete.

WireGuard: AllowedIPs je smerovacia tabuľka

Na klientovi AllowedIPs uvádza ciele, ktoré môžu vstúpiť do tunela, a wg-quick mení každý záznam na obyčajnú cestu. Klientska polovica tejto úlohy je teda jeden riadok.

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

Teraz porovnajte záznam servera pre toho istého klienta. Opisuje, čo server pošle klientovi, čo je zvyčajne adresa tunela klienta, nie privátna podsieti.

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

Zámena týchto dvoch je chyba, ktorú vidím najčastejšie. Umiestnenie 10.20.0.0/16 pod peer sekciu servera tvrdí, že celá podsieti leží za týmto klientom, a to je nárok od lokality k lokalite, nie povolenie. Pakety, ktoré nezodpovedajú AllowedIPs žiadneho peera, sa ticho zahadzujú, takže nesprávny záznam vyzerá presne ako problém s firewallom.

Ak cesty spravujete sami, nastavte Table = off pod [Interface] a pridajte cestu, ktorú chcete. Potom sa nič nepridáva automaticky, takže cesta patrí k tomu, čo dvíha rozhranie.

OpenVPN: pošlite cestu a potom sa uistite, že dorazila

Na bežnom serveri je zmena jedna direktíva v konfigurácii servera, vedľa fondu klientov.

push "route 10.20.0.0 255.255.0.0"

Klient ju pridá pri pripojení. Režim zlyhania sa prejaví, keď ten istý profil posiela aj redirect-gateway, alebo keď niekto už pridal route-nopull: prvé urobí zo sedenia plný tunel, druhé zahodí každú poslanú cestu vrátane vašej.

Klient, ktorý potrebuje úzke správanie voči serveru s plným tunelom, má ignorovať len tie časti, ktoré nechce. V OpenVPN 2.4 a novšom existuje pull-filter presne na to.

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

Držte adresné rodiny oddelene: poslaná cesta IPv4 nič nerobí pre internú službu, ktorá sa prekladá na IPv6, a tá služba zlyhá cez tunel, kým všetko ostatné vyzerá v poriadku.

Keď privátna podsieti nie je na VPN serveri, ale za iným klientom, server o tom musí vedieť. Pridajte súbor pre každého klienta cez client-config-dir obsahujúci iroute 10.20.0.0 255.255.0.0, plus zodpovedajúcu route, aby sa ostatní klienti naučili cestu. Bez iroute server nemá dôvod posielať tento prefix práve týmto tunelom.

IPsec: selektory premávky sa musia zhodnúť

Pri IPsec nie je žiadna cesta na odoslanie. Obe strany vyjednajú, ktoré adresy žijú vnútri tunela, a premávka mimo dohodnutých selektorov sa ani nešifruje, ani cez ne neposiela. Na klientovi strongSwan sú selektory výslovné.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Ak je brána nakonfigurovaná s 0.0.0.0/0 na oboch stranách, zúženie IKEv2 zvyčajne zredukuje podriadenú SA na prienik oboch návrhov, čo je želaný výsledok. Niektoré brány namiesto toho odmietnu návrh, ktorý nezodpovedá ich nakonfigurovaným selektorom, a log potom ukáže zlyhanú podriadenú SA, nie sťažnosť na smerovanie. Keď sa to stane, zmena patrí bráne, pretože cesta na klientovi nemôže vytvoriť tunel pre selektor, ktorý druhá strana neprijme.

V Windows zabudovaný klient skrýva to isté rozhodnutie za dvoma nastaveniami. Rozdelenie tunela musí byť zapnuté a prefix musí byť zaregistrovaný v profile.

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

Práve registrácia prefixu mu umožňuje prežiť opätovné pripojenie, čo cesta pridaná ručne nedokáže.

Držte koncový bod a DNS mimo rozhodnutia

Koncový bod VPN musí zostať dostupný bez tunela, inak sa tunel zrúti do seba. Keď sa smeruje len 10.20.0.0/16, je to automatické, pretože koncový bod je verejná adresa. V profile plného tunela to tak nie je a klient potrebuje výslovnú cestu k hostiteľovi koncového bodu predtým, než sa tunel zdvihne.

DNS je druhé rozhodnutie, ktoré za vás odoslanie cesty neprijme. Interné názvy sa zvyčajne prekladajú cez resolver dostupný len z privátnej siete. Ak server posiela DNS server, každý názov ide cez neho; ak nie, interné názvy buď zlyhajú, alebo sa verejne preložia na niečo, čo ste nemali v úmysle. Rozdelené DNS drží jednu vyhľadávaciu doménu na internom resolveri, ale to závisí od podpory klienta, preto to berte ako samostatnú úlohu, nie ako vedľajší účinok smerovania.

Overte, potom reštartujte a overte znova

Tri sondy pokrývajú otázku smerovania. Spýtajte sa jadra, kam by išla vzdialená adresa, stiahnite niečo zvnútra podsiete a potom potvrďte, že bežná verejná požiadavka stále vychádza vaším normálnym pripojením.

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

Prvý riadok pomenúva rozhranie. Ak pomenúva vaše fyzické rozhranie, cesta nikdy nedorazila. V Windows Find-NetRoute -RemoteIPAddress 10.20.5.7 odpovedá na tú istú otázku a posledná sonda by stále mala ukazovať vašu obvyklú adresu, nie adresu VPN servera.

Potom reštartujte. Cesty pridané ručne zmiznú, kým cesty z profilu, z poslanej konfigurácie alebo z AllowedIPs sa vrátia. Ak úzky prístup funguje pred reštartom a po ňom zlyhá, chyba je v tom, ako tunel štartuje, nie v samotnej ceste.

Skôr než to vyhlásite za hotové, potvrďte štyri veci: prefix prišiel od správcu siete a neprekrýva nič lokálne, spätná cesta existuje alebo ju nahrádza pravidlo maskovania, mechanizmus, ktorý ste nakonfigurovali, je ten, ktorý vynucuje smerovanie na vašej platforme, a tie isté sondy prejdú po čistom reštarte. Poznámky strongSwan k preposielaniu stoja za prečítanie, ak je spätná cesta tou časťou, ktorá stále zlyháva.

Súvisiace články