Kuckt wéi den Tunnel eropkënnt an de Client déi aner Säit pingt, an duerno äntwert eng öffentlech Adress déi hannert dem VPN gehéiert vun enger anerer Plaz, oder guer net. Dëst Symptom huet normalerweis näischt mam Chiffrement oder de Zertifikater ze dinn. E Prefix deen de Provider routet gëtt als IP-Route geliwwert, an e fiert iwwer OpenVPN ze vermëttelen heescht déi Route op zwou Niveauen ze reproduzéieren an d’Quelladress um Retourwee ze behalen. De WAN ze bridge ass net néideg, an d’Adress op eng Interface ze setzen schaaft net déi iewescht Route.

De Prefix muss als éischt zu Iech geroutet ginn

Frot de Provider wéi de Block geliwwert gëtt. E Prefix deen op d’Haaptadress vun Ärem Server geroutet gëtt ass eppes anescht wéi Adressen déi de Provider direkt op engem WAN-Segment erwaart. Nëmmen deen éischte Modell funktionnéiert mat dem Design hei.

Wann de Provider 198.51.100.64/28 op Ären Entrées-Server routet, kommen d’Pakete fir dëse Beräich um Server un a bleiwen do stoen, ausser Dir leet se weider. Wann de Provider de Beräich amplaz op Ären Uplink bridgt, muss de Server ARP dofir äntweren, wat en anert Problem ass.

Test den Delevue-Modell ier Dir OpenVPN beréiert: ping bausse vun enger Adress aus dem Block a kuckt wéi eng Interface se kritt. Wann näischt ukommt, hëlleft keng Tunnelkonfiguratioun. Wann d’Adress direkt um WAN äntwert, bridgt de Provider amplaz ze routen, an d’Design hei drënner gëllt net.

Zwee Routing-Niveauen: Kernelroute an iroute

OpenVPN brauch de Prefix op zwou Plazen. De Kernel muss wëssen datt de Prefix zum Tunnelapparat gehéiert, sou datt weidergeleete Paketen an OpenVPN ginn amplaz an d’Standardroute. OpenVPN muss och wëssen wéi en authentifizéierte Client de Prefix besëtzt, an dat ass de iroute-Aschreiwung am clientspezifeschen Dossier.

D’Route op der Serversäit gesäit sou aus, woubäi de Prefix a d’Mask zu der Zoustellung musse passen:

ip route add 198.51.100.64/28 dev tun0

Déi clientspezifesch Konfiguratioun vergëtt d’Eegentum. Setzt se an d’CCD-Fichier déi nom gemeinsamen Numm vum Clientzertifikat benannt ass, a bestätegt datt dësen Dossier deen ass deen de Server tatsächlech liest:

iroute 198.51.100.64 255.255.255.240

D’Dokumentatioun vun OpenVPN iwwer geroutete Netzwierker beschreift béid Niveauen a firwat se separat sinn. Eng Kernelroute ouni iroute schéckt Paketen ouni Besëtzer an den Tunnel, an OpenVPN verwëft se. En iroute ouni d’Kernelroute léisst d’Paketen op dem Standardwee vum Server. Béid Feeler gesinn aus Clientsiicht aus wéi en gebrochenen Tunnel.

Wou d’Serviceadress wunnt

De delegéierte Prefix ass net datselwecht wéi d’eegen Adressen vum Tunnel. Numeréiert d’Verbindung aus dem private Raum wann Dir wëllt, a setzt d’öffentlech Serviceadress do wou de Service tatsächlech leeft.

Op engem Linux-Client deen de Service lokal terminéiert ass eng eenzeg Hostadress genuch:

ip address add 198.51.100.70/32 dev lo

Wann de Prefix weider op en VM-Host oder en anert LAN geroutet gëtt, konfiguréiert amplaz deen Downstream-Wee a seng Retourroute. Et ass net néideg all Adress aus dem Block dem VPN-Client zouzedeelen, an et schaaft spéider Konflikter.

Behält d’öffentlech Quell um Retourwee

Eng Äntwert aus dem delegéierte Prefix muss duerch den Tunnel erausgoen an d’Route vum Provider erreechen. Wann den entfernten Host se iwwer säin eegenen ISP schéckt, gesäit d’Quelladress gefälscht aus, an de Provider oder den Zil verwëft se. D’Léisung ass eng quellbaséiert Regel oder eng dedizéiert Routingtabell, net e méi breede NAT. Ouni déi funktionéiert de Service vum Tunnelpartner aus a versoe vu jidder anerer Plaz.

Um Entrées-Server ass eng breet masquerade-Regel de gewéinlechen Täter. Si schreift d’öffentlech Quell op d’Haaptadress vum Server ëm, an de Client gesäit ni déi richteg:

iptables -t nat -S POSTROUTING

Limitéiert NAT op déi privat VPN-Cliente déi et brauchen a loosst de delegéierte Prefix oniwwersetzt. Bestätegt duerno datt de Server de Prefix iwwerhaapt weiderleet, well eng Weiterleetungskette mat Standardverweigerung se stëll verwerft.

Verifizéiert béid Richtungen ier Dir et vertraut

D’Verifikatioun ass véier Observatiounen, net eng. Bestätegt datt d’Route vum Provider ukommt, de Kernel de Prefix an den Tunnel schéckt, OpenVPN en dem richtegen Client zoudeelt, an d’Äntwert mat der öffentlecher Quell intakt zréckkënnt. All Observatioun huet hiren eegene Kommando, sou datt e Feeler op eng Schicht weist an net op d’ganzt Design. Fëllt se an där Rei no all Konfiguratiounsännerung aus.

Frot de Kernel wéi ee Wee eng delegéiert Adress hëlt, a kuckt den Tunnel wärend eng Ufro leeft:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

D’Filtere vum ëmgekéierte Wee kann eng korrekt Route zerlabe maachen. Kontrolléiert d’effektiv Astellung um Tunnel an um Uplink, a denkt drun datt en strikte Modus Verkéier verwërft deem seng Quell net zu der Interface passt op déi en ukomm ass:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Fir d’Schluss, test de Feelerfall. Stopp den Tunnel a bestätegt datt de öffentleche Prefix net iwwer den normale Uplink leakt. D’VPN restauréieren soll de Service zréckbréngen ouni ze erweideren wéi eng Porte den Host exposéiert.

Ähnlech Artikelen