PiVPN-Handshake funktionéiert, Säiten hänken: kontrolléiert d'MASQUERADE

Däin Telefon weist den Tunnel als verbonnen, de Client mellt eng privat Adress, an déi éischt Säit hänkt nach an der Mëtt vum Lueden. Dës Kombinatioun schéckt déi meescht Leit an d'Verschlësselungsastellungen an an d'CPU-Temperatur, wou eigentlech näischt futti ass. Den Tunnel ass eropkomm, also war d'Aushandlung fäerdeg; dat, wat versot huet, ass de Schrëtt duerno, wann de Server probéiert d'Clientpäckchen un den Internet ze iwwerginn. Gitt dee selwechte Wee wéi dës Päckchen, an d'Diskrepanz ass meeschtens an enger Zeil vun der NAT-Tabell ze gesinn.

Fänkt domat un, wat de Client erreeche kann an wat net

Vum verbonnenen Client, luet eng Säit, déi um öffentlechen Internet läit, a notéiert ob se direkt versot oder hallefierdes hänkt. Dann opmaacht eng Ressource op der eegener privater Adress vum VPN-Server a vergläicht déi zwee Resultater.

Eng Tunneladress, déi op ping äntwert, während öffentlech Site mat der Zäit erauslafen, ass d'Zeeche vun engem Weiderleitungs- oder Iwwersetzungsproblem, net vun engem futti Handshake. D'Statuspanel vum Client selwer kann déi zwee net ënnerscheeden, well et just weess, datt de Kontrollkanal erop ass. Kontrolléiert um Server d'Tunnelinterface mat ip -br addr show tun0 a bestätegt, datt d'Adress, déi de Client krut, am Pool läit, deen Dir konfiguréiert hutt. Wann de Pool an d'Clientadress net iwwerenee stëmmen, reparéiert dat als éischt, well all Regel hei drënner mam Pool iwwerenee stëmmt.

Frot dann de Server, wéi eng Interface en benotze géif, fir eng öffentlech Adress z'erreechen. ip route get 203.0.113.9 dréckt dat gewielten Apparat an d'Quell an hirer éischter Zeil. Schreift den Apparatnumm op, well dat ass de Wäert, deen d'NAT-Regel enthalen muss.

Liest d'Regel, déi entscheet, ob d'Päckchen erausginn

MASQUERADE schreift e Päckchen nëmmen ëm, wann et duerch d'Interface geet, déi an der Regel genannt ass. Eng Regel, déi op en Apparat mat Kabel begrenzt ass, mécht näischt fir den Traffic, deen iwwer Wi-Fi erausgeet, an d'Päckche behält seng privat Quelladress bis zum ieweschten Router. Dee Router huet keng Route zréck an Äre Tunnelpool, dofir verwerft en d'Äntwert, an de Client gesäit eng Verbindung, déi sech opmécht an duerno stierft. D'Symptom wiisst mat deem, wéi vill vun der Säit ukënnt, ier déi éischt Äntwert gebraucht gëtt.

Lëscht d'lieweg Tabell op a liest d'Kolumne vun der Ausgangsinterface, amplaz just no dem Wuert MASQUERADE ze sichen. D'Ausgab an der Zousatzform ass méi einfach ze vergläichen wéi eng formatéiert Lëscht:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Op engem Raspberry Pi, deen eemol Ethernet an elo Wi-Fi benotzt, ass den ale Numm bal ëmmer déi ganz Geschicht. Den Installateur huet festgehalen, wéi en Apparat beim Setup do war, an de gespäicherte Regelset spillt en bei all Start erëm of. Vergläicht den Apparat aus der Routensich mam Apparat an der Regel, ier Dir eppes anescht ännert. Wann se iwwerenee stëmmen, ass d'Interface net Äre Problem an Dir sollt op d'Compteur am leschte Sektioun goen. Wa se sech ënnerscheeden, ass d'Korrektur eng Ännerung vun engem Wuert an der Persistenzdatei.

Korrigéiert de gespäicherte Regelset, net nëmmen deen, deen leeft

Nëmmen d'lieweg Tabell z'änneren hält bis zum nächsten Neistart, an dat ass just laang genuch fir Iech ze iwwerzeegen, datt de Problem geléist ass. D'Reegelen, déi beim Start zréckkommen, liewen an enger Datei, déi e Firewall-Persistenzpaket nei lued. Op Debian-baséierten Pi-Images ass déi Datei meeschtens /etc/iptables/rules.v4.

Maacht eng Kopie, ier Dir se beréiert, ersetzt dann d'Ausgangsinterface an der MASQUERADE-Zeil duerch den Apparat, deen Dir opgeschriwwen hutt, zum Beispill -o wlan0 amplaz -o eth0. Loosst de Quellberäich wéi en ass, ausser Äre Clientpool huet sech geännert. Lued nei a bestätegt, datt d'Regel elo den richtegen Apparat nennt:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Zwee benopte Astellungen vergiess een einfach. sysctl net.ipv4.ip_forward muss 1 mellen, an den ieweschten Router däerf privat Quelladressen net selwer filteren.

Beweist, datt d'Regel gräift, an isoléiert dann, wat nach lues ass

D'Compteur sinn deen eenzegen éierleche Beweis, datt eng Regel getraff huet. Fuert déi ausféierlech Lëscht aus, start engem Download um Client a fuert se nach eng Kéier aus. D'Pak- a Byte-Kolonne nieft Ärer Regel sollten klammen, an eng Regel, déi op null bleift, trëfft nach ëmmer net. Wann d'Compteur sech bewegen, awer d'Säiten nach ëmmer versoen, vergläicht de Quellberäich mam tatsächleche Pool mat grep -n "^server " /etc/openvpn/server.conf. Wann se sech bewegen an d'Säite lueden, awer den Duerchfloss schlecht ass, ass d'Iwwersetzung fäerdeg an de Rescht vum Problem ass soss anzwousch.

Vergläicht zwee Transferten vum selwechte Client, een op en Host am lokalen Netz an een duerch den Tunnel op de selwechten Host. Lues a béide Fäll weist op den ieweschte Link vum Pi oder d'Wi-Fi-Verbindung, net op de VPN. Lues nëmmen duerch den Tunnel weist op MTU an Neisendungen, déi Dir mat ip -s link show tun0 iwwerpréiwen kënnt, ier Dir eng Krypto-Astellung ännert.

Fir den Experiment réckgängeg ze maachen, setzt d'Kopie zréck a lued se nach eng Kéier, a bestätegt dann, datt déi ursprénglech Regel an hir Compteur zréck sinn. Schreift den Ausgangsapparat an de Neiluedbefehl an d'Servernotizen, well déi nächst Ännerung vum ieweschte Link déiselwecht Diskrepanz erëm entdeckt. Eng Regel, déi de falschen Apparat nennt, bleift onsichtbar, bis den Traffic se brauch.