Wêrom't ien subnet noch altyd jo VPN-standertrûte omgiet
Ien subnet dat ûnder in folsleine tunnel direkt giet, betsjut meastentiids dat in langer foarheaksel wint, gjin lek. Kontrolearje heale standertrûtes, beliedsregels en profylútsûnderingen.
Jo skeakelje de VPN oer nei folsleine tunnel, it measte ferkear heart, en dan antwurdet ien adres direkt — in printer, in NAS, in spronghost op 10.x. De foar de hân lizzende lêzing is dat de tunnel lekt, dus jo ferleegje de metryk op 'e standertrûte en neat feroaret. Dy mislearre poging is de oanwizing: in standertrûte is in fallback, gjin oardiel. De rûtesyktocht nimt it langste oerienkommende foarheaksel foardat it ea metryken fergeliket, dus in /24 bliuwt winne fan in /0, hokker getal jo ek oan ien fan beiden hingje. As dy oardering dúdlik is, is it lek meastentiids in rûte dy't immen mei opsetsin ynstallearre hat, of in foarheaksel dat de klant nea fan doel wie te dekken.
Wat in standertrûte echt belooft
0.0.0.0/0 komt oerien mei elke IPv4-bestimming mei nul bits spesifisiteit. It bestiet sadat in host alles berikke kin dat syn tabel net better beskriuwt. In rûte nei 192.168.1.0/24 draacht 24 oerienkommende bits, dus foar 192.168.1.40 wint er foardat immen metryken, bestjoerlike ôfstân of hoe't de klant syn prioriteitsfjild ek neamt fergeliket. Deselde regel jildt yn 'e Linux-FIB, de Windows-rûtetabel en de BSD-stapel efter macOS.
Op in normaal LAN is dat gedrach in funksje. It lokale subnet is direkt oanhechte, de printer bliuwt wurkje wylst de tunnel jo browsen draacht, en neat is ferkeard konfigurearre. De fraach dy't it wurdich is om te stellen is net wêrom't dat iene adres direkt giet, mar hokker foarheaksel yn hokker tabel dermei oerienkomt, en wa't it dêr set hat.
Heale standertrûtes, of wêrom't de standertynfier ûnoantaasten lykje kin
It skjinste foarbyld is redirect-gateway def1 by OpenVPN. Ynstee fan jo standert fuort te smiten en te ferfangen, foeget it 0.0.0.0/1 en 128.0.0.0/1 ta. Tegearre dekt it pear hiel IPv4, elk foarheaksel is langer as /0, en beide ferslaan de standert fan 'e router wylst se dy op syn plak litte. Rin dêrnei in rûtelist en de oarspronklike standert is der noch, wiist noch nei jo gateway; hy wurdt gewoan nea keazen foar internetbestimmingen.
wg-quick fan WireGuard berikt deselde útkomst fia beliedsrouting. As AllowedIPs 0.0.0.0/0 dekt, makket it syn eigen tabel, stjoert markearre pakketten dêrhinne en foeget in regel ta dy't it foarheaksel fan nul lingte fan 'e haadtabel negearret. De haadtabel hâldt syn standertynfier, en de regels beslute dat de tunneltabel earst rieplachte wurdt foar it ferkear dat de ynterface besit.
Beide ûntwerpen hawwe krekt ien rûte bûten de tunnel nedich: in hostrûte nei it eigen adres fan 'e VPN-tsjinner fia de oarspronklike gateway. Sûnder dy soe de klant besykje de pakketten dy't de tunnel bouwe yn 'e tunnel te dragen, en de ferbining komt nea klear. In net-tunnelrûte yn jo tabel is dêrom normaal sels op in strang folslein-tunnelprofyl. De rûtes dy't it freegjen wurdich binne, binne dejingen dy't bestimmingen dekke dêr't jo echt om jouwe.
Metryken beslisse gelykens, foarheaksels beslisse winners
Metryken wurde allinnich fergelike ûnder kandidaten dy't likegoed by de bestimming passe. Op Linux ip route get 10.20.5.9 printsje de winner tegearre mei syn tabel, en ip route show table all listet de kandidaten op, ynklusyf alle heale standertrûtes en elke tabel dêr't in regel nei wiist. Op Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 jout de keazen rûte en boarneadres werom, wylst Get-NetRoute de rûwe tabel sjen lit — mar de effektive kosten binne rûtemetryk plus ynterfacemetryk, dus in stadige adapter kin in gelykens ferlieze dy't er skynber wint.
Trije gefallen dekke it measte fan wat jo sjen sille:
- Deselde bestimming, /24 tsjin /0: de /24 wint op foarheakselflingte, wat de metryken ek sizze.
- Deselde bestimming, twa /24's mei ferskillende metryken: de legere effektive metryk wint.
- Deselde bestimming, twa tabellen, ien keazen troch in beliedsregel: de regel kiest earst de tabel, en foarheakselfergeliking bart deryn.
It tredde gefal is wêr't de measte fan dizze rapporten einigje. In Linux ip rule of in Windows VPN-ferkearsfilter kin ferkear nei in tabel stjoere dy't nea de tunnelstandert hie, en de haadtabel liket de hiele tiid perfekt.
Wa't de omgong meastentiids besit
Begjin by it profyl, net by de tabel. Split-tunnelkonfiguraasjes en VPN-ynstellingen per app litte mei opsetsin neamde foarheaksels bûten de tunnel; in wurkprofyl dat ien privee subnet beskermet en algemien browsen direkt gean lit, docht sa't it ûntwurpen is, en it oerskriuwen brekt it belied dat it fiere moast. De VPN-rûtegids fan Microsoft lûkt deselde grins tusken twongen tunnelferkear en eksplisite útsûnderingen, wat it in nuttige krúsjefergeliking makket foardat jo eat bewurkje.
Sykje dêrnei nei oerbliuwsels. In rûte dy't nei in ynterface wiist dy't net mear bestiet, of nei in adres fan it foarige netwurk, ferskynt neidat dokstasjons, USB-adapters en containerbrêgen komme en gean. It ien kear fuortsmite is net it ein: NetworkManager-ferbiningsprofylen, netplan-bestannen en permaninte Windows-rûtes ynstallearje it by de folgjende ferbining of opstart op 'e nij, dus fyn it bestân of profyl dat it besit foardat jo eat bewurkje.
Kontrolearje dan IPv6 apart. ip -6 route en Get-NetRoute -AddressFamily IPv6 hâlde aparte steat, aparte standertrûtes en apart klantgedrach. In audit fan allinnich IPv4 seit neat oer in dual-stack-host dy't stil in native IPv6-paad foarkomt, en dat allinnich kin in klant split-tunnel lykje litte.
Befêstigje mei de eigen stream fan 'e applikaasje
Skriuw de bestimming op dy't de applikaasje echt brûkt, freegje dan it systeem nei it paad dat it nimme soe fan it boarneadres dêr't dy applikaasje oan bynt. ip route get 10.20.5.9 from 192.168.1.40 beantwurdet dat op Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus it lokale adres docht it op Windows. Fergelykje it resultaat mei wat it profyl beweart. De iepenbiere-IP-side fan in browser testet ien bestimming op ien protokol en seit neat oer it privee adres dat de klacht begûn.
Reparearje it smelste objekt dat it ferskil ferklearret. As de útsûndering goedkard is, skriuw it foarheaksel op en lit it gewurde; as net, ferwiderje de rûte of foegje in eksplisite smellere rûte troch de tunnel ta ynstee fan de metryk fan 'e standert te ferleegjen. In metryk ferleegje kin in langer foarheaksel net oertreffe, en de standert bewurkje wylst twa /1-rûtes it internetpaad besitte feroaret ek neat.
Ferbyn de tunnel dêrnei op 'e nij en werhelje deselde fraach. Klanten ynstallearje rûtes by elke ferbining op 'e nij, dus in feroaring dy't allinnich oant de folgjende handshake hâldt is net test. As it paad noch ôfwikt, binne de oerbleaune fertochten in beliedsregel, in twadde tabel of in filter oan 'e klantkant — net de standertrûte.
- Neam de bestimming en it boarneadres dat de app echt brûkt.
- Printsje de winnende rûte mei
ip route getofFind-NetRoute. - Kontrolearje oft in /1-paar of in beliedstabel it internetpaad besit.
- List elk foarheaksel langer as /0 op dat by de bestimming past.
- Werhelje de IPv6-kontrôle apart.
- Spoar de oerlibjende rûte werom nei it bestân, profyl of filter dat dy ynstallearret.
- Ferbyn op 'e nij en rin de fraach nochris, foardat jo it reparearre neame.
As alle sân mei it profyl oerienkomme, docht de tunnel krekt wat er konfigurearre wie om te dwaan, en de reparaasje heart yn it profyl, net yn in metryk.