Zwee VPN-Clienten, eng Routentabell: wien gewënnt d'Standardroute
Zwee VPN-Cliente stoussen seelen direkt openeen; si iwwerschreiwen déiselwecht Standardroute. Kontrolléiert de gewielte Wee an da stoppt ee Client, all Destinatioun ze behaapten.
Et gesäit aus wéi wann zwee VPN-Cliente sech ëm dee selwechte Socket streiden, an déi offensichtlech Léisung muss sinn, een ze deinstalléieren. An der Praxis beréieren si seelen dee selwechte Socket. All Connexioun schreift d'Routentabell vum Betribssystem ëm, an e Volltunnelprofill behaapt d'Standardroute. Dee leschten, deen ugeschloss huet, gewënnt meeschtens, an dofir gesäit et aus wéi wann de Symptom tëscht de Clienten hin an hier wandert.
De Konflikt läit an der Routentabell
En virtuelle Adapter plus eng Standardroute ass wéi en Volltunnel den Traffic fänkt. Wann den zweete Client seng eege Standardroute installéiert, gëtt dee méi alen Asaz ersat oder duerch d'Metrik erofgesat, an all Destinatioun geet elo duerch den méi neien Tunnel. Den éischte Client bleift verbonnen a weist nach ëmmer e grénge Symbol, also ass d'Interface un, während de Wee fort ass. Genau dës Trennung tëscht Verbindungszoustand a Routingzoustand mécht d'Verhalen verwirrend.
D'Cliente sinn Editeure vun enger gedeelter Tabell. Ze wëssen, wéi eng Ännerung déi lescht war, erklärt bal all Symptom.
Liest, wéi en Tunnel de momentanen Wee besëtzt
Kontrolléiert déi tatsächlech Entscheedung, amplaz dem Client ze vertrauen, dee sech als verbonnen mellt. Frot de System, wéi eng Interface eng bestëmmt Destinatioun géif droen.
ip route get 10.20.0.5
route print -4Den éischte Befehl nennt d'Interface an d'Quelladress fir eng Destinatioun, an dat ass genau d'Fro, déi Iech intresséiert. D'Routelëscht weist op Windows déi konkurréierend Standardasätz a hir Metriken, sou datt Dir gesitt, wien de Moment gewënnt. Fuert d'Sich fir en Host an all fernen Netzwierk aus, well eng Destinatioun richteg ka sinn, während dat anert Netzwierk net erreechbar ass. Wann d'Äntwert den falschen Tunnel nennt, hëlleft nei verbannen net; d'Routëpolitik muss sech änneren.
Stoppt den zweete Client, alles ze behaapten
Ee Client soll d'Standardroute besëtzen, an deen aneren nëmmen seng eege Prefixen droen. OpenVPN Cliente kënne refuséieren, wat de Server erafdréckt.
pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10route-nopull ignoréiert all erofgedréckt Route, während pull-filter ignore "redirect-gateway" nëmmen d'Direktiv vun der Standardroute verwërft an déi erofgedréckt DNS an aner Optiounen hält. Wielt tëscht hinnen no wéi vill vun der Serverkonfiguratioun Dir nach wëllt, a füügt dann déi spezifesch Prefixen derbäi, déi dat zweet Netzwierk brauch. Denkt un DNS, well en Resolver, deen vun engem Tunnel erofgedréckt gëtt, deen d'Ufroe net dréit, guer näischt zréckgëtt. Testt een bekannten Host an all Netzwierk a bestätegt d'Quelladress, déi déi wäit Säit gesäit.
Iwwerlappend Subnetzer loosse sech net ëmgoen
Wann béid Netzwierker deeselwechte Prefix publizéieren, hält de Kär ee Asaz fir zwou verschidde Plazen a muss wielen. Eng Hostroute kann den ënnerscheed net erfinden, an eng Metrikupassung och net. Nummeréiert eng Säit nei, oder loosst hire Administrateur de fernen Beräich iwwersetzen, sou datt d'Prefixen sech ënnerscheeden. Kontrolléiert déi richteg Subnetzer, ier Dir de Clienten d'Schold gitt, well de Standard vun engem Heemrouter 192.168.1.0/24 méi dacks mat engem Bürosberäich kollidéiert wéi een erwaart. Schreift béid Beräicher an den Ticket, sou datt déi nächst Ännerung d'Iwwerlappung net nei schaaft.
Trennt och zwee Ziler: béid Netzwierker z'erreechen ass e Routingproblem, während d'Kette vun Tunnelen fir Privatsphär en anert Design ass mat engem zousätzlechen Operateur um Wee. Benotzt net dat engt, fir dat anert ze léisen.