LAN-Router plus VPN-Client: zwee Apparater, zwou Routing-Tabellen

Zwee Apparater leede de Pak weider an all een hält seng eege Tabell. De LAN-Router weess, datt dee entfernte Prefix zum VPN-Client gehéiert, an de VPN-Client weess, wéi hien dee Prefix duerch säin Tunnel erreecht. Konfiguréier just d’éischt Tabell an de Pak kënnt bei engem Apparat un, deen keng passend Route huet, sou datt en erëm iwwer d’Standardroute erausgeet. Dat ass de ganzen Defekt, an aus der Sicht vum LAN gesäit et aus wéi eng Routing-Schleef, well et bal eng ass.

Zeechent déi zwee Hoppen, ier Dir eng Route beréiert

Huelt eng illustrativ Astellung: LAN-Hosts op 192.168.50.0/24, den normale Router op 192.168.50.1, en dedizéierte Client op 192.168.50.15 an eng wäit LAN op 10.60.0.0/24, déi nëmmen duerch den Tunnel erreechbar ass, deen dëse Client hält. Keen vun deenen zwou private Beräicher iwwerlappt deen aneren, an den Tunnel huet säin eegene Adressplang.

Béid privat Beräicher sinn wichteg, well se entscheeden, wéien Apparat äntweren kann. D’Géigendeck gesäit de Pak vun der Tunneladress vum Client ukommen, an hir Äntwert muss e Wee zréck op 192.168.50.0/24 fannen. Wann nëmmen d’Richtung eraus konfiguréiert ass, ka d’Ufro funktionéieren, während d’Äntwert verschwënnt.

Schrëtt 1: riicht de Router op de Client, net op den Tunnel

Um LAN-Router, füügt eng Destinatiounsroute derbäi, deenen hiren nächsten Hop d’LAN-Adress vum Client ass:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Dee Rekord seet „liwwer en un de Apparat, dee kann tunnelen“. En seet näischt doriwwer, wéi den Tunnel gebaut gëtt, an en ersetzt net dem Client seng eege Route. Op engem geréierte Router läit d’Äquivalent op der Säit vun den stateschen Routen vum Apparat; op engem Linux-Router gehéiert et zu der Interface-Konfiguratioun, déi d’LAN besëtzt, net an eng Shell, déi Dir zoumaacht.

Kuckt d’Äntwert vum zweeten Uerder. Wann en de Client als gateway an d’LAN-Interface als device mëttelt, ass den éischten Hop richteg an de Rescht vun der Aarbecht ass um aneren Apparat.

Schrëtt 2: gitt dem Client eng eege Route op der Tunnelsäit

De Client kritt elo e Pak fir 10.60.0.0/24 a kuckt a senger eege Tabell. Wann seng Tunnelkonfiguratioun eng Route fir dee Prefix installéiert huet, geet de Pak verschlësselt weider. Wann net, passt de Pak op d’normal Standardroute a geet zréck op 192.168.50.1, deen en erëm un de Client schéckt.

Kuckt, ier Dir eppes derbäisetzt:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Eng fehlend Prefixroute an allen Tabellen ass dee Fonnt, deen Dir sicht. Füügt se iwwer d’Tunnelkonfiguratioun selwer derbäi, sou datt déi nächst Reconnectioun se erëm installéiert; eng manuell ip route add verschwënnt mat der Sessioun a mécht, datt de Fehler am ongënschtegste Moment zréckkënnt. Den nächsten Hop ass den Tunnelinterface oder d’Adress, déi d’VPN als säi Peer vergëtt, ofhängeg vum Client, an d’Peeradress soll aus dem aktuellen Profil kommen an net aus enger aler Notiz.

D’Schleef ass, wann se geschitt, an der Praxis net onendlech: den TTL fält bei all Passage an de Pak stierft mat enger Meldung iwwer eng iwwerschratt Zäit. Dofir kann en erëmholte traceroute eng Zyklus suggeréieren, während e Client, deen einfach net weiderleet, dee selwechte Pak stëll fale léisst.

Schrëtt 3: erlaabt d’Weiderleeden a wielt de Retourwee

Empfänken a Weiderleede sinn ënnerschiddlech Berechtegungen. net.ipv4.ip_forward=1 um Client erlaabt Transit um Kernel-Niveau, an eng Firewall-Reeg muss et nach ëmmer tëscht dem LAN-Interface an dem Tunnel erlaben. Eng Reeg, déi den Zougang zu der Client senger eegener Verwaltungssäit erlaabt, erlaabt keen Transit op d’wäit LAN, an den Ënnerscheed ass liicht ze iwwersinn, wann dee selwechten Host lokal op Pings äntwert.

D’Géigendeck huet de Spigelproblem. Si muss wëssen, datt 192.168.50.0/24 iwwer dësen authentifizéierte Client erreechbar ass. Mat OpenVPN bedeit dat normalerweis eng Route pro Client, déi d’Serverkonfiguratioun dréckt, oder eng clientspezifesch Datei um Server, déi d’LAN hannert dem Client deklaréiert. Ouni dat läit d’wäit LAN d’Äntwert fale oder schéckt se op hire eigenen Standardgateway, also an den Internet.

Quellübersetzung ass d’Alternativ, wann de LAN-Prefix net annoncéiert ka ginn. Eng limitéiert Masquerade-Reeg um Client schreift d’Quell op d’Tunneladress ëm, an d’Äntwerten kommen dann natierlech zréck. Et verstoppt och, wéien en LAN-Host d’Ufro gemaach huet, an et erlaabt vun sech aus net der Géigendeck, Verbindungen no bannen unzefänken. Wielt dee Kompromiss bewosst, statt eng blanket Masquerade derbäizesetzen an den Nieweneffekt méi spéit ze entdecken.

Schrëtt 4: maacht béid Entscheedungen dauerhaft, an test dann de richtege Wee

All Route huet en Eegentümer, an den Eegentümer ass d’Konfiguratioun, déi beim Booten oder beim Reconnect erëm entsteet. Um Router kann dat en stateschen Route-Antrag sinn; um Client kann et de VPN-Profil, NetworkManager oder systemd-networkd sinn. Verifizéiert andeems Dir den Tunnel erëm verbënnt an de Client nei start, an liest dann d’Tabell erëm, amplaz der Ännerung ze vertrauen.

Hält d’Standardroute, déi d’baussen Verbindung vum Tunnel dréit, intakt. Se ze ersetzen fir d’Setup ze „vereinfachen“ brécht de verschlësselte Wee, ier en iergendeen bannenzege Traffic ka benotzen, an de Symptom ass en Tunnel, deen no der Ännerung ni méi erëm opgebaut gëtt.

Test vun engem normale LAN-Host, net vum Client, well eng Ufro, déi um Client entsteet, ni den éischten Hop vum Router ausübt. Huelt e Service, deen et nëmmen op der wäiter LAN gëtt, a bestätegt de Kierper vun der Äntwert, a kuckt dann d’Comptoiren oder d’Logge vum Client, fir den Transit ze gesinn. En internen traceroute, deen privat Hoppe weist, beweist Weiderleeden, net Verschlësselung: de baussenzege Wee ass eng separat Observatioun, a nëmmen d’Interface-Comptoire vum Tunnel selwer weisen, wat duerch en erausgaang ass.