Een privaten Ënternetz duerch den Tunnel an alles anescht iwwer Ären normale Wee ass eng kleng Ufro mat ville Weeër, et falsch ze maachen. D'Resultat entscheet net d'Këscht mam Numm split tunneling, mä wou d'Entscheedung ëmgesat gëtt: an der Rouentabell vum Client selwer, an enger Route déi de Server dréckt, oder an enger Politik déi déi zwou Säiten ausmécht. Wielt déi falsch Schicht a kritt entweder en vollstännegen Tunnel, deen Dir ni wollt, oder eng Route an en Tunnel, deen déi aner Säit refuséiert ze akzeptéieren. Ech benotze virum Opmaache vun enger Konfiguratioun en Test mat dräi Bedéngungen an wielen duerno ee vun de Mechanismen hei drënner.

Dräi Bedéngungen déi den Design entscheeden

Éischtens braucht Dir de geneeë Prefix an d'Mask vum Netzwierkbesëtzer. Den 10.x-Netzwierk ass kee Prefix; 10.20.0.0/16 ass een. Kontrolléiert datt en Iech net mat Ärem Heem-LAN, enger Docker-Bréck oder engem aneren VPN iwwerschneid, well eng Iwwerschneidung d'Route méideuteg mécht an de Kernel den Entrée wielt, deen Dir net gemengt hutt.

Zweetens, wien de Récktrafic beäntwert. E Pak an den Tunnel ze leeden bréngt en just op de VPN-Server. Wann d'Ënternetz hannert engem aneren Router läit, deen eng Route zréck an Äre Clientpool huet, muss de Server den Trafic maskéieren, oder dee Router muss Äre Pool léieren. Keng Route op der Clientsäit reparéiert e feelende Réckwee.

Drëttens, de Punkt vun der Ëmsetzung. E puer Clienten installéieren eng Route an d'Betribssystem mécht de Rescht. Anerer handelen eng Politik aus, an eng Politik, déi de Gateway net akzeptéiert, mécht iwwerhaapt keen Tunnel: d'Pakete ginn ouni kloer Feeler verworf. Fënnt eraus wien vun deenen zwee Äre Fall ass, ier Dir eppes schreift.

WireGuard: AllowedIPs ass d'Rouentabell

Um Client zielt AllowedIPs d'Ziler op, déi an den Tunnel dierfen, an wg-quick mécht aus all Entrée eng gewéinlech Route. Also ass d'Client-Halschent vun dëser Aufgab eng eenzeg Zeil.

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

Vergläicht elo den Entrée vum Server fir dee selwechte Client. E beschreift wat de Server un de Client schéckt, an dat ass normalerweis d'Tunneladress vum Client, net d'privat Ënternetz.

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

Dës zwee ze vertauschen ass de Feeler, deen ech am heefegsten gesinn. 10.20.0.0/16 ënner dem peer-Abschnitt vum Server ze setzen erkläert, datt dat ganzt Ënternetz hannert deem Client läit, an dat ass eng Usproch vu Site zu Site, keng Erlaabnis. Pakete mat deenen keen peer seng AllowedIPs iwwereneestemmt ginn doudeg verworf, dofir gesäit en falschen Entrée genee wéi e Firewallproblem aus.

Wann Dir d'Routen selwer verwalt, setzt Table = off ënner [Interface] a füügt d'Route bäi déi Dir wëllt. Dann gëtt näischt automatesch bäigefüügt, dofir gehéiert d'Route zu deem wat den Interface eropbréngt.

OpenVPN: dréckt d'Route an da suergt dofir, datt se ukënnt

Op engem normale Server ass d'Ännerung eng eenzeg Direktiv an der Serverkonfiguratioun, nieft dem Clientpool.

push "route 10.20.0.0 255.255.0.0"

De Client füügt se bäi wann en sech verbënnt. De Feelfall weist sech wann dee selwechte Profil och redirect-gateway dréckt, oder wann een schonn route-nopull bäigefüügt huet: dat éischt mécht aus der Sëtzung en vollstännegen Tunnel, dat zweet verwërft all gedréckt Route, och Är.

E Client dee sech géint en Volltunnel-Server schmuel verhalen soll, soll nëmmen déi Deeler ignoréieren déi en net wëll. An OpenVPN 2.4 a méi nei gëtt et pull-filter genee dofir.

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

Halt d'Adressfamilljen ausernee: eng gedréckt IPv4-Route mécht näischt fir en internen Déngscht deen op IPv6 opgeléist gëtt, an deen Déngscht fält iwwer den Tunnel, während alles anescht gutt ausgesäit.

Wann dat privat Ënternetz net um VPN-Server läit, mä hannert engem aneren Client, muss de Server informéiert ginn. Füügt iwwer client-config-dir eng Datei pro Client bäi mat iroute 10.20.0.0 255.255.0.0, plus déi passend route, sou datt aner Clienten de Wee léieren. Ouni iroute huet de Server kee Grond dee Prefix just duerch deen Tunnel ze schécken.

IPsec: d'Trafficselektoren musse sech eens ginn

Bei IPsec gët et keng Route ze drécken. Déi zwou Säiten handelen aus wéi eng Adressen am Tunnel liewen, an den Trafic baussent de vereenbarte Selektoren gëtt weder verschlësselt nach duerch de Tunnel geschéckt. Op engem strongSwan-Client si Selektoren explizit.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Wann de Gateway op béide Säiten mat 0.0.0.0/0 konfiguréiert ass, reduzéiert d'IKEv2-Verengung de Kanner-SA meeschtens op de Schnëttpunkt vun den zwou Virschléi, wat d'gewënscht Resultat ass. E puer Gateways verwäerfen dogéint e Virschlag deen net zu hire konfiguréierte Selektoren passt, an de Log weist dann en duerchgefallene Kanner-SA anstatt eng Beschwéierde iwwer Routing. Wann dat geschitt gehéiert d'Ännerung op de Gateway, well eng Clientroute keen Tunnel fir een Selektor ka schafen deen déi aner Säit net akzeptéiert.

Op Windows verstoppt den agebaute Client déi selwecht Entscheedung hannert zwou Astellungen. D'Tunnelsplit muss un sinn, an de Prefix muss um Profil registréiert ginn.

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

Et ass d'Registréierung vum Prefix déi en eng Neiverbindung iwwerstoe léisst, wat eng vun Hand bäigefüügt Route net mécht.

Halt den Endpunkt an DNS baussen der Entscheedung

Den VPN-Endpunkt muss ouni den Tunnel erreechbar bleiwen, soss fält den Tunnel an sech selwer zesummen. Wann nëmmen 10.20.0.0/16 gerout gëtt ass dat automatesch, well den Endpunkt eng ëffentlech Adress ass. Op engem Volltunnelprofil ass et dat net, an de Client brauch eng explizit Hostroute bis zum Endpunkt ier den Tunnel eropkënnt.

DNS ass eng zweet Entscheedung déi e Routendrëck net fir Iech hëlt. Intern Nimm ginn normalerweis iwwer e Resolver opgeléist deen nëmmen dat privat Netzwierk erreeche kann. Wann de Server en DNS-Server dréckt geet all Numm duerch deen; wann net, da fale intern Nimm entweder aus oder ginn ëffentlech op eppes opgeléist wat Dir net gemengt hutt. Splitt-DNS hält eng Sichdomain um internen Resolver, mä dat hänkt vun der Clientënnerstëtzung of, also behandelt et als eege Aufgab an net als Niewenwirkung vum Routing.

Iwwerpréift, start dann nei a préift nach eng Kéier

Dräi Proben decken d'Routingfro of. Frot de Kernel wou eng wäit Adress higéing, sicht eppes aus dem Ënneren vum Ënternetz, a bestätegt dann datt eng gewéinlech ëffentlech Ufro nach ëmmer iwwer Är normal Verbindung erausgeet.

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

Déi éischt Zeil nennt en Interface. Wann se Ären physeschen Interface nennt, ass d'Route ni ukomm. Op Windows äntwert Find-NetRoute -RemoteIPAddress 10.20.5.7 op déi selwecht Fro, an déi lescht Prob soll nach ëmmer Är gewéinlech Adress weisen an net déi vum VPN-Server.

Start dann nei. Routen déi vun Hand bäigefüügt goufen verschwannen, während Routen aus dem Profil, aus enger gedréckter Konfiguratioun oder aus AllowedIPs zeréckkommen. Wann de schmuele Zougang virum Neistart funktionéiert an duerno feelt, läit de Feeler doran wéi den Tunnel start, net an der Route selwer.

Ier Dir et fäerdeg nennt, bestätegt véier Saachen: de Prefix kënnt vum Netzwierkbesëtzer a just iwwereneestemmt mat näischt Lokalem, de Réckwee existéiert oder eng Maskeradsregel ersetzt en, de Mechanismus deen Dir konfiguréiert hutt ass deen deen d'Routing op Ärer Plattform ëmsetzt, an déiselwecht Proben passéieren no engem propere Neistart. D'Notizen vun strongSwan zum Weiderschécken si liesenswäert wann de Réckwee deen Deel ass deen ëmmer erëm feelt.

Ähnlech Artikelen