Mat OpenVPN verbonnen, awer näischt lued: en Duerchgang vum Client aus

Den Tunnel steet an de Browser dréit ëmmer nach. Schaff vum Client no baussen: zwee Opnamen, ee Kernelsschalter, déi richteg Ausgangsinterface, duerno DNS.

D'Fënster vum Client seet Connected, d'Tunneladress ass do, an de Browser dréit ëmmer nach. Dës Kombinatioun ass normal, well e gelungene Handshake just beweist, datt den Tunnel gebaut gouf; ee seet näischt doriwwer, ob de Server Är Pakete weiderleet, hir Quell ëmschreift oder Är DNS-Ufroen beäntwert. De Feeler, deen déi meescht Leit maachen, ass fir d'éischt dem Server seng Konfiguratioun opzemaachen. Schaff amplaz vum Client no baussen, well all Schrëtt hei drënner seet Iech, ob den nächsten iwwerhaapt nachzegoe wäert ass.

Fänk beim Client un a schaff no baussen

Maach dräi Tester an dëser Reihenfolg a schreif op, wou den éischten duerchfält. Ping dem Server seng Tunneladress, wat beweist, datt den Tunnel selwer Traffic dréit. Ping eng ëffentlech Adress no der Nummer, wat Weiderleedung an Iwwersetzung beweist, ouni Nummaufléisung mat anzebezéien. Probéier duerno en Hostnumm opzeléisen, wat den eenzegen Test ass, deen DNS benotzt. All Resultat hëlt eng ganz Schicht aus dem Verdacht.

Sprang net op den drëtten Test, well en Browser sech méi séier ufillt. En duerchgefallene Säitelued deckt all dräi Schichten op eng Kéier of, an et ass genau do, wou d'Leit ufänken an duerno en Tunnel, deen funktionéiert huet, nei bauen. Eng Säit, déi duerchfält, seet Iech net, wéi eng vun den dräi kaputt ass.

Zwee Opnamen weisen, wou d'Pakete stoppen

Wärend e Ping op eng ëffentlech Adress vum Client aus leeft, huel een Opnam op der Tunnelinterface an een um Uplink, deen d'Internet soll erreechen. Looss béid gläichzäiteg lafen, sou datt d'Zäitstemple matenee passen.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Wann d'Ufroen um Tunnel erschéngen an ni um Uplink, huet de Server se tëscht dem Tunnel an dem Kabel verkaaft, an d'Ursaach ass Weiderleedung oder d'Forward-Politik vun der Firewall, net NAT. Wa se op béide erschéngen, huet de Server säin Deel gemaach an d'Äntwert feelt nach méi wäit dobaussen, wat op Iwwersetzung, e Filter uewendriwwer oder eng Aschränkung vum Provider hiweist.

Huel den Numm vum Uplink aus der Routingtabell, net aus engem Tutoriel. Cloudbiller an ëmbenannte Adapter passen seelen zu der Beispillinterface an engem Guide, an en Opnam um falschen Apparat gesäit genee aus wéi e Server, deen net weiderleet:

ip -4 route get 9.9.9.9

D'Feld dev an där Ausgab ass den Numm, deen d'NAT-Reeg méi spéit brauch, also behalt en.

Weiderleedung ass en Kernelsschalter an eng Firewallpolitik

De Kernel muss iwwerhaapt averstane sinn ze weiderleeden. Liest den aktuellen Wäert a maach d'Astellung duerno dauerhaft, amplaz se just an de lafende Kernel ze schreiwen:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Weiderleedung ass just d'Halschent. Op engem Host mat UFW gëtt d'Forward-Politik an /etc/default/ufw gesat an muss ACCEPT sinn, ier en Neiopluede wierkt. En Standard-Drop um Forward-Wee léisst den Handshake komplett gesond, verkaaft awer stëll all Paket, dat probéiert duerch den Tunnel erauszekommen, an dat ass genee de Symptom, mat deem Dir ugefaangen hutt.

Hosten, déi nftables direkt verwalten, hunn déiselwecht Fro an enger anerer Syntax. Kuckt d'Zieler op der Forward-Kette, während en Clienttest leeft, well eng Kette, déi consultéiert gëtt, an eng Kette, déi verkaaft, an enger Konfiguratiounsdatei gläich ausgesinn.

Nenn déi richteg Ausgangsinterface an der NAT-Reeg

Quellenn-Iwwersetzung gehéiert op d'Interface, déi den Host wierklech verléisst, mat dem Pool, deen de Server verdeelt. Béid Halschente vun där Reeg mussen d'Realitéit beschreiwen, an keng vun hinne ass fakultativ.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

De klassesche Feeler ass eng Reeg, déi aus engem Guide kopéiert gouf an -o eth0 seet op enger Maschinn, där hiren Adapter anescht heescht. D'Reeg installéiert sech ouni Warnung, passt op näischt, an de Client huet nach ëmmer keen Internet. De Pool ass déi aner Halschent vum selwechte Feeler: wann de Server 10.44.0.0/24 verdeelt an d'Reeg 10.8.0.0/24 deckt, wäert ni eppes passen.

Kuckt d'Zieler, amplaz dem Text vun der Reeg ze vertrauen. D'Lëscht mëllt Pakete pro Reeg, an eng Reeg, déi ni passt, bleift op null, sou richteg wéi se och ausgesäit. Gitt hir eng Minutt richtege Clienttraffic, ier Dir eppes an déi Zuel eralest:

iptables -t nat -L POSTROUTING -v -n

En Nuellpaket-Zieler no engem richtege Clienttest heescht, datt de Match falsch ass, net datt den Tunnel futti ass. Soubal en passt, späichert de Reegelsatz, sou datt en en Neistart iwwerlieft; eng Korrektur, déi just an Ärer Shell-Historique lieft, verschwënnt beim éischten Neistart.

Wann de Server och eng Cloud-NAT-Instanz ass, huet d'Plattform och eng Stëmm. Eng Instanz, déi Adressen iwwersetzt, brauch normalerweis d'Quellen- an d'Zilprüfung ausgeschalt, wou de Provider déi Astellung ubitt, an de VPN-Port selwer muss vu baussen erreechbar sinn.

DNS ass den zweeten Ausfall hannert dem éischten

Ping no Adress, dee funktionéiert, während Nimm duerchfalen, ass e Resolverproblem, an et huet seng eege Ursaach. En Client, deen säi lokale Resolver behält, schéckt déi Ufroen an en vollstännegen Tunnel an waart op eng Äntwert, déi ni kënnt, well de lokale Resolver elo op der falscher Säit vun der Route ass.

Schub e Resolver vum Server, sou datt de Client weess, wou en froe soll. Zwou Entréen ginn dem Client en Ersatz, wann déi éischt net erreechbar ass, a béid sollten Resolver sinn, déi den Tunnel wierklech erlaabt.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows-Cliënte kënnen duerno trotzdem op de lokale Resolver zréckfalen, an et ass genee dat, wat block-outside-dns existéiert fir ze verhënneren, op Käschte vun Nimm, déi just dat lokal Netzwierk ka léisen. Linux-Cliënte mat systemd-resolved ignoréieren dacks e geschubte Resolver, ausser e Skript installéiert en, also kontrolléiert resolvectl status fir den Tunnelapparat, ier Dir schléisst, datt de Schub ignoréiert gouf.

Fäerdeg den Duerchgang esou, wéi en Benotzer en erlieft. Lued eng richteg Säit vum Client, bestätegt d'Adress, vun där se erauskënnt, start de Server nei, verbann dech nei a widderhuel déi dräi Tester. Just déi zweet Ronn beweist, datt déi gespäichert Reegele, d'Firewallpolitik an de geschubte Resolver all zesummen iwwerlieft hunn.

Ähnlech Artikelen