Tunnel steet, keen Internet: wou d'Weiderleedung ophält
Authentifizéierung an en funktionéierenden Tunnel heesche nach keen Internetausgang. Verfollegt eng eenzeg Ufro duerch d'Quelladresséierung, d'Weiderleedung an de Réckwee.
De Client verbënnt sech, den Tunnel dréit Pings bis op de Gateway, a baussent deem äntwert näischt. Dee Zustand ass normal fir e Gateway, deen ëmmer just den Zougang zu geschützten Netzwierker sollt ubidden, an et ass e Feeler fir eent, dat als Volltunnel-Ausgang ugekündegt gëtt. Ier Dir Regelen ännert, bestätegt wéi en Service versprach gouf. Verfollegt duerno eng eenzeg ëffentlech Ufro duerch déi véier Plazen, wou se stoppe kann. Eng Ufro an eng Paketofléchung klären méi wéi eng Säit mat Vermutungen.
Bestätegt, ob den Internetausgang je d'Design war
E Split-Tunnel-Profil leet just déi geschützt Subnetzer an de VPN, dofir geet d'ëffentlech Surfen iwwer de lokale Link weider an de Gateway gëtt ni beréiert. E Volltunnel-Profil installéiert eng Standardroute an den Tunnel, wat de Gateway fir de ganze Wee verantwortlech mécht. Op béide sinn et legitim Designen, an hir Verwiesslung produzéiert e Feelerbericht, wou keen ass. Liest dem Client seng ugekündegt Routen, ier Dir eppes anescht testt, well d'Routentabelle beäntwert d'Fro, déi den Ticket meeschtens falsch stellt.
Wat de Client installéiert, ass net ëmmer dat, wat de Profil bezweckt. Eng gepushte Route kann duerch eng lokal Route mat niddereger Metrik iwwerschriwwe ginn, an e Client, deen seng LAN-Route behält wärend en eng Standardroute dobäi setzt, verhält sech wéi en Split-Tunnel fir dee Subnetz.
Verfollegt eng eenzeg ëffentlech Ufro
Wielt eng eenzeg Destinatioun a verfollegt se vum Client no baussen. Um Client kontrolléiert, ob de Pakett tatsächlech den Tunnel wielt a wéi eng lokal Adress en als Quell benotzt. Kontrolléiert duerno de Gateway: kënnt de Pakett un, a verléisst en déi ëffentlech Interface. Jiddwer vun dësen Äntwerten eliminéiert eng ganz Kategorie vun Ursaachen.
ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1
Wann de Gateway de Pakett ni gesäit, ass d'Client-Route oder d'Tunnelwahl falsch. Wann en ukënnt an net fortgeet, ass de Problem um Gateway, an déi dräi verbleiwen Kontrollen zielen.
Kontrolléiert Weiderleedung, Route an Iwwersetzung
D'Weiderleedungsguide, déi mat strongSwan geliwwert gëtt, gëllt fir e Gateway vun all Tunneltyp: de Kernel muss däerfe Paketter tëscht Interfaces beweegen, an eng brauchbar Route muss Richtung Internet weisen. D'Firewall-Politik muss duerno den Traffic erlaaben, an d'Quelladress muss eng sinn, op déi déi ëffentlech Säit äntwere kann. Eng privat Clientadress, déi onverännert an den Internet weidergeleet gëtt, kritt ni eng Äntwert.
sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter
Quell-Iwwersetzung ass de gewéinlech fehlenden Deel. Domat schreift de Gateway d'Clientquell op seng ëffentlech Adress ëm a verfollegt de Floss; ouni dat huet d'Äntwert niergendwou hin. Cloud-Plattformen fügen eng zweet Grenz bäi, wou d'Routentabelle oder d'Sécherheetsgrupp vun der Instanz Traffic verwerfe kann, deen d'Firewall vum Gaascht erlaabt. Déi Grenz ass liicht ze iwwersinn, well de Gaaschtsystem vun bannen korrekt konfiguréiert ausgesäit.
D'Filterung vum ëmgedréinte Wee an enger asymmetrescher Konfiguratioun kann och gülteg Paketten verwerfen. Liest de Compteur vun där Regel, amplaz unzehuelen, et wier an der Rei, well eng streng Astellung op der ëffentlecher Interface Traffic ofweist, deen iwwer en anere Wee ukënnt wéi d'Routentabelle viraussoet.
Réckwee a Resolver sinn zwou verschidden Äntwerten
Passt och op d'Äntwert op, net just op d'Ufro. Wann d'Ufro iwwersat erausgeet an d'Äntwert an den iwwersate Floss zeréckkënnt, funktionéiert d'Weiderleedung och wann d'Applikatioun nach ëmmer feelt, an déi nächst Enquête gehéiert zu der Applikatioun oder zu DNS.
Eng Säit, déi en HTTP-Fehler zréckschéckt, ass de Beweis, datt d'Weiderleedung an den Internet funktionéiert. En Numm, dee sech net opléist, während den Zougang iwwer d'Adress funktionéiert, ass e Resolverproblem, keen NAT-Problem.
Testt no enger enker Korrektur de Client nach eng Kéier souwéi all bewosst limitéiert privat Ressource. Internet-Zougang ze ginn däerf den Zougang net stëll op all Netzwierk ausdehnen, dat um Gateway hänkt.