Ären zweeten Client verbënnt, d’Ressourcen vum éischten hale op ze léisen, an den Ticket seet, d’Aarbechts-VPN hätt dat perséinlecht futti gemaach. Et ass näischt futti am Sënn vun engem Fehler: béid Cliente hunn dat gemaach, wofir si entwéckelt goufen, an d’Maschinn huet nëmmen eng Routingtabell. D’Kollisioun geet ëm véier Ressourcen, déi all Client als seng eege ugesäit. Schafft se der Rei no of, an d’Léisung gëtt meeschtens eng Designentscheedung amplaz vun enger Reparatur.

Schrëtt 1: fannt eraus, wéi ee Client den Ausgang besitzt

Liest déi aktuell Ausgangsentscheedung, ier Dir eppes ännert. D’Routensich fir eng ëffentlech Adress seet Iech, wéi eng Interface an wéi ee nächsten Hop e Paket just elo benotze géif, an dat ass d’Äntwert drop, wien gewonnen huet. Vergläicht dat mat den Interface-Nimm, déi d’Cliente ugeluecht hunn, déi meeschtens den Numm vum Produkt oder Protokoll droen. Wann d’Sich op den Tunnel weist, deen Dir net erwaart hutt, hutt Dir d’Kollisioun schonn fonnt.

ip route get 1.1.1.1
ip route show default
route print

E puer Cliente ersetzen den Standardwee guer net; si fügen zwou Hälften dobäi, eng fir déi ënnescht Hallschent vum Adressraum an eng fir déi iewescht, déi zesummen alles ofdecken. Dat léisst den ursprénglechen Standardwee siichtbar a léisst eng manuell Reparatur richteg ausgesinn, wärend den Traffic nach ëmmer duerch den Tunnel erausgeet. Liest d’Metrik an d’Längt vum Prefix, net nëmmen d’Präsenz vun engem Standardagang.

Stoppt, wann béid Cliente dee selwechte Prefix mat der selwechter Metrik behaapten. De Kernel wielt een, an deen aneren erschéngt verbonnen, wärend en näischt dréit.

Schrëtt 2: kontrolléiert de Resolver an déi iwwerlappend Prefixen

DNS ass déi zweet Kollisioun, an et produzéiert e markant Symptom: Nimm schloen fehl, wärend Adressen funktionéieren. All Client dréckt säin eegene Resolver duerch, an de leschte Schreiwer gewënnt fir déi nächst Ufroen. Frot de Resolver-Service, wat en pro Verbindung benotzt, amplaz d’Astellunge-Säit vum Client ze liesen.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Vergläicht dann déi privat Prefixen, déi déi zwou Netzwierker benotzen. Wa béid Säiten aus dem selwechten Beräich verdeelen, wäert keng Client-Säit-Regelung dat fixen, well d’Maschinn net soe kann, wéi en 10.0.0.0/8-Zil zu wéi engem Tunnel gehéiert. Eng Säit muss ëmnummeréiert oder iwwersat ginn, an dat ass e Gespréich mat den Netzwierkbesëtzer amplaz vun enger Konfiguratiounsännerung. D’Iwwerlappung ass déi eenzeg Kollisioun, wou déi éierlech Äntwert ass, datt den Design muss geännert ginn.

Stoppt hei, wann d’Prefixen iwwerlappen. Alles wat duerno an dëser Lëscht kënnt, setzt viraus, datt se et net maachen.

Schrëtt 3: wielt en Trennungsmuster, deen hält

Déi zouverlässeg Muster vermeiden et, zwee Cliente géint déiselwecht Routingtabell lafen ze loossen. Een eenzege Client mat enger Split-Tunnel-Politik, déi béid privat Netzwierker erreecht ass deen einfachsten, soulaang d’Ziler sech net iwwerlappen an den Eegentemer vun der Politik averstanen ass. Eng virtuell Maschinn oder en Netzwierk-Namespace ass den nächste Schratt, well all eenzel seng eegen Tabell a säin eegene Resolver kritt.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

En Namespace gëtt déiselwecht Trennung wéi eng virtuell Maschinn ouni dat zweet Betribssystem, awer et huet rau Kanten: den Tunnelapparat muss doranner geréckelt ginn, an d’Applikatioun muss dobannen ugefaange ginn. En getrennten physeschen Apparat ass dacks déi mannst iwwerraschend Optioun fir eng perséinlech VPN nieft engem verwalteten Aarbechtsclient. Een Tunnel an en aneren ze stapelen ass keen Trennungsmuster; den banneschten Endpunkt muss duerch den äussersten Tunnel erreechbar bleiwen, an d’Arrangement bäit och MTU- a Latenzproblemer dobäi.

Wielt ee Muster a schreift op firwat. En Namespace fir eng Applikatioun mat engem Split-Tunnel fir de Rescht ze mëschen, baut d’ursprénglech Kollisioun a manner einfach ze debugger Form nei.

Schrëtt 4: verifizéiert béid Netzwierker aus der selwechter Sitzung

Testt eng Ressource op all privat Netzwierk aus der Ëmfeld, wou d’Applikatioun wierklech leeft, net aus Ärer Shell, wann d’App am Namespace leeft. Kontrolléiert d’Ausgangsinterface, déi opgeléist Adress an de Responscode zesummen, well en Erfolleg an engem vun den dräi e Fehler an den aneren verstoppe kann. Widderhëlt et no engem Neistart, well d’Reiefolleg, an där d’Cliente starten, entscheet, wien gewënnt. Genau déi Reiefolleg vergiesse Leit ze notéieren.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Notéiert d’Clientversiounen, d’Interface, de Resolver-Zoustand an d’Prefixen fir all Netzwierk. Wann e Client aktualiséiert gëtt a säi Routenverhalen ännert, ass déi Opzeechnung den Ënnerscheed tëscht enger Fënnef-Minutte-Reparatur an engem Neibau. Déi nächst Persoun wäert Äert Gediechtnes net deelen, wéi en Tunnel als éischten eropkomm ass.

D’Lëscht ass komplett, wann Dir d’Interface nenne kënnt, déi den Standardwee besitzt, de Resolver, deen all Numm benotzt, d’Muster, dat den zweeten Tunnel trennt, an d’Resultat vun enger Ufro pro Netzwierk no engem Neistart. Alles manner ass eng Konfiguratioun, déi haut zoufälleg funktionéiert.

Ähnlech Artikelen