Hoe't jo mar ien privee-subnet troch de VPN stjoere

Ien privee-subnet troch de tunnel en al it oare oer jo gewoane paad is in lyts fersyk mei in soad manieren om it ferkeard te dwaan. Wat de útkomst beslút is net it oanfinkfak mei de namme split tunneling, mar wêr't it beslút útfierd wurdt: de eigen rûtetabel fan 'e klant, in rûte dy't de tsjinner triuwt, of in belied dat de beide kanten ûnderhannelje. Kies jo de ferkearde laach, dan krije jo of in folsleine tunnel dy't jo nea woene, of in rûte nei in tunnel dy't de oare kant wegeret te akseptearjen. Ik brûk in test mei trije betingsten foardat ik hokker konfiguraasje dan ek iepenje, en kies dan ien fan 'e meganismen hjirûnder.

Trije betingsten dy't it ûntwerp beslisse

Earst hawwe jo it krekte foarheaksel en de masker fan 'e netwurk-eigner nedich. It 10.x-netwurk is gjin foarheaksel; 10.20.0.0/16 is dat. Befêstigje dat it net oerlaapet mei jo thús-LAN, in Docker-brêge of in oare VPN dy't jo draaie, want in oerlaap makket de rûte dûbelsinnich en de kearn kiest it ynfier dat jo net bedoelden.

Twadde, wa't it weromkommende ferkear beantwurdet. In pakket nei de tunnel rûte bringt it allinnich by de VPN-tsjinner. As it subnet efter in oare router sit dy't gjin rûte werom hat nei jo klantpôle, dan moat de tsjinner it ferkear maskerje, of dy router moat jo pôle leare. Gjin rûte oan 'e klantkant ferhelpt in ûntbrekkend werompaad.

Tredde, it útfieringspunt. Guon klanten ynstallearje in rûte en it bestjoeringssysteem docht de rest. Oaren ûnderhannelje in belied, en in belied dat de poarte net akseptearret leveret hielendal gjin tunnel op: pakketten wurde weilitten sûnder in dúdlike flater. Fyn út hokker fan 'e twa jo hawwe foardat jo wat skriuwe.

WireGuard: AllowedIPs is de rûtetabel

Op 'e klant listet AllowedIPs de bestimmingen op dy't de tunnel yn meie, en wg-quick makket fan elk ynfier in gewoane rûte. De klanthelte fan dizze taak is dus ien rigel.

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

Fergelykje no it ynfier fan 'e tsjinner foar deselde klant. Dat beskriuwt wat de tsjinner nei de klant stjoert, en dat is meastentiids it tunneladres fan 'e klant, net it privee-subnet.

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

It omwikseljen fan dy twa is de flater dy't ik it meast sjoch. It pleatsen fan 10.20.0.0/16 ûnder de peer-seksje fan 'e tsjinner bewissiget dat it hiele subnet efter dy klant leit, en dat is in oanspraak fan side nei side, gjin tastimming. Pakketten dy't net mei de AllowedIPs fan ien peer oerienkomme wurde stilwei weilitten, dus in ferkeard ynfier liket krekt op in firewallprobleem.

As jo de rûtes sels beheare, set dan Table = off ûnder [Interface] en foegje de rûte ta dy't jo wolle. Dan wurdt neat automatysk tafoege, dus de rûte heart by wat de ynterface omheech bringt.

OpenVPN: triuw de rûte en soargje der dan foar dat it oankomt

Op in gewoane tsjinner is de feroaring ien rjochtline yn 'e tsjinnerkonfiguraasje, neist de klantpôle.

push "route 10.20.0.0 255.255.0.0"

De klant foeget it ta as er ferbynt. De flatermodus docht him foar as itselde profyl ek redirect-gateway triuwt, of as immen al route-nopull tafoege hat: it earste makket de sesje in folsleine tunnel en it twadde smyt elke tatriuwde rûte fuort, ek dyn.

In klant dy't smel gedrach nedich hat tsjin in folslein-tunnel-tsjinner, moat allinnich de dielen negearje dy't er net wol. Yn OpenVPN 2.4 en letter bestiet pull-filter krekt dêrfoar.

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

Hâld adresfamyljes apart: in tatriuwde IPv4-rûte docht neat foar in ynterne tsjinst dy't nei IPv6 oplost, en dy tsjinst falt oer de tunnel wylst al it oare goed liket.

As it privee-subnet net op 'e VPN-tsjinner stiet mar efter in oare klant, moat de tsjinner dat witte. Foegje in bestân per klant ta fia client-config-dir mei iroute 10.20.0.0 255.255.0.0, plus de byhearrende route sadat oare klanten it paad leare. Sûnder iroute hat de tsjinner gjin reden om dat foarheaksel krekt troch dy tunnel te stjoeren.

IPsec: de ferkearsselekteurs moatte it iens wurde

By IPsec is der gjin rûte om te triuwen. De beide kanten ûnderhannelje hokker adressen yn 'e tunnel libje, en ferkear bûten de ôfsprutsen selekteurs wurdt net fersifere en net der troch stjoerd. Op in strongSwan-klant binne de selekteurs eksplisyt.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

As de poarte oan beide kanten mei 0.0.0.0/0 konfigurearre is, ferlytset IKEv2-ferlinging de bern-SA meastentiids ta it krúspunt fan 'e twa foarstellen, en dat is de útkomst dy't jo wolle. Guon poarten wegerje ynstee in foarstel dat net mei har konfigurearre selekteurs oerienkomt, en it lochboek toant dan in mislearre bern-SA ynstee fan in rûteklacht. As dat bart, heart de feroaring by de poarte, want in klantrûte kin gjin tunnel meitsje foar in selekteur dy't de oare kant net akseptearret.

Op Windows ferberget de ynboude klant itselde beslút efter twa ynstellingen. Tunnelferdieling moat oan wêze, en it foarheaksel moat by it profyl registrearre wurde.

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

It registrearjen fan it foarheaksel is wat it in werferbining oerlibje lit, wat in mei de hân tafoege rûte net docht.

Hâld it einpunt en DNS bûten it beslút

It VPN-einpunt moat berikber bliuwe sûnder de tunnel, oars stoart de tunnel yn himsels yn. As allinnich 10.20.0.0/16 rûte wurdt, is dat automatysk, om't it einpunt in iepenbier adres is. Op in folslein-tunnelprofyl is dat net sa, en de klant hat in eksplisite hostrûte nei it einpunt nedich foardat de tunnel omheech komt.

DNS is in twadde beslút dat in rûtetriuw foar jo net nimt. Ynterne nammen oplosse meastentiids fia in oplosser dêr't allinnich it privee-netwurk by kin. As de tsjinner in DNS-tsjinner triuwt, giet elke namme der troch; docht er dat net, dan mislearje ynterne nammen of oplosse se iepenbier nei eat dat jo net bedoelden. Ferspjalte DNS hâldt ien sykdomain op 'e ynterne oplosser, mar dat hinget fan klantstipe ôf, dus behannelje it as in eigen taak ynstee fan in bywurking fan rûtering.

Ferifiearje, start dan opnij op en ferifiearje wer

Trije probes dekke de rûtefrage. Freegje de kearn wêr't in ôfstân-adres hinne soe, helje wat fan binnen it subnet, en befêstigje dan dat in gewoan iepenbier fersyk noch altyd fia jo normale ferbining nei bûten giet.

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

De earste rigel neamt in ynterface. As er jo fysike ynterface neamt, is de rûte nea oankommen. Op Windows beantwurdet Find-NetRoute -RemoteIPAddress 10.20.5.7 deselde fraach, en de lêste probe moat noch altyd jo gewoane adres sjen litte ynstee fan dat fan 'e VPN-tsjinner.

Start dan opnij op. Rûtes dy't mei de hân tafoege binne ferdwine, wylst rûtes út it profyl, út in tatriuwde konfiguraasje of út AllowedIPs weromkomme. As smelle tagong foar it opnij starten wurket en dêrnei mislearret, sit de flater yn hoe't de tunnel begjint, net yn 'e rûte sels.

Foardat jo it klear neame, befêstigje fjouwer dingen: it foarheaksel kaam fan 'e netwurk-eigner en oerlaapet neat lokaal, it werompaad bestiet of in maskeringsregel ferfangt it, it meganisme dat jo konfigurearre hawwe is dat wat rûtering op jo platfoarm útfiert, en deselde probes slagje nei in skjinne werstart. De notysjes fan strongSwan oer trochstjoeren binne it lêzen wurdich as it werompaad it diel is dat hieltyd mislearret.