Zergatik saihesten duen azpisare batek oraindik zure VPNaren lehenetsitako bidea

VPNa tunel osora aldatzen duzu, trafiko gehienak obeditu egiten du, eta orduan helbide batek zuzenean erantzuten du — inprimagailu bat, NAS bat, 10.x-ko jauzi-host bat. Irakurketa begi-bistakoa da tunelak ihes egiten duela, beraz lehenetsitako bidearen metrika jaisten duzu eta ezer ez da aldatzen. Saiakera huts hori da arrastoa: lehenetsitako bidea ordezko aukera da, ez epaia. Bide-bilaketak metrikak konparatu aurretik prefijo luzeena hartzen du, beraz /24 batek /0 baten aurka irabazten jarraitzen du, biei zenbaki edozein erantsita ere. Ordena hori argi dagoenean, ihesa normalean norbaitek nahita instalatutako bide bat da, edo bezeroak inoiz estaltzeko asmorik ez zuen prefijo bat.

Zer agintzen duen lehenetsitako bide batek benetan

0.0.0.0/0-k IPv4 helmuga guztiekin bat egiten du zero espezifikazio-bitekin. Host batek bere taulak hobeto deskribatzen ez duen edozer irits dezan existitzen da. 192.168.1.0/24-rako bide batek 24 bit parekide daramatza, beraz 192.168.1.40-rako irabazten du inork metrikak, distantzia administratiboa edo bezeroak lehentasun-eremu deitzen duena konparatu aurretik. Arau bera Linux FIB-en, Windowsen bide-taularen eta macOS atzean dagoen BSD pilan balio du.

LAN arrunt batean portaera hori ezaugarri bat da. Azpisare lokala zuzenean konektatuta dago, inprimagailuak lanean jarraitzen du tunelek zure nabigazioa daraman bitartean, eta ezer ez dago gaizki konfiguratuta. Galdetzea merezi duen galdera ez da helbide hori zergatik doan zuzenean, baizik eta zein taulatan zein prefijok egiten dion bat, eta nor arduratu zen han jartzeaz.

Erdi-lehenetsitako bideak, edo zergatik dirudi lehenetsitako sarrerak ukitu gabe

Adibiderik garbiena redirect-gateway def1 da OpenVPNn. Zure lehenetsitako bidea ezabatu eta ordezkatu beharrean, 0.0.0.0/1 eta 128.0.0.0/1 gehitzen ditu. Elkarrekin bikotea IPv4 osoa estaltzen du, prefijo bakoitza /0 baino luzeagoa da, eta biek routerraren lehenetsitakoa gainditzen dute hura bere tokian utzita. Exekutatu bide-zerrenda bat gero, eta jatorrizko lehenetsitakoa oraindik han dago, oraindik zure atebidera seinalatzen; besterik gabe ez da inoiz interneteko helmugarako hautatzen.

WireGuarden wg-quickek emaitza bera lortzen du politika-bideratzearen bidez. AllowedIPs-ek 0.0.0.0/0 estaltzen duenean bere taula propioa sortzen du, markatutako paketeak hara bidaltzen ditu, eta taula nagusiaren zero luzerako prefijoa alde batera uzten duen arau bat gehitzen du. Taula nagusiak bere lehenetsitako sarrera gordetzen du, eta arauek erabakitzen dute interfazeak duen trafikorako tunel-taula kontsultatzen dela lehenengo.

Bi diseinuek tunelaz kanpoko bide bat behar dute zehazki: host-bide bat VPN zerbitzariaren beraren helbidera jatorrizko atebidearen bidez. Hura gabe, bezeroak tunela eraikitzen duten paketeak tunelaren barruan eramatea saiatuko litzateke, eta konexioa ez litzateke inoiz osatuko. Beraz, zure taulan tunelak ez duen bide bat normala da tunel osoaren profil zorrotzean ere. Zalantzan jartzea merezi duten bideak axola dizkizuten helmugak estaltzen dituztenak dira.

Metrikek berdinketa erabakitzen dute, prefijoek irabazlea

Metrikak helmugarekin berdin bat egiten duten hautagaien artean baino ez dira konparatzen. Linuxen, ip route get 10.20.5.9 irabazlea bere taularekin batera inprimatzen du, eta ip route show table all hautagaiak zerrendatzen ditu, erdi-lehenetsitako edozein bide eta arau batek seinalatzen duen edozein taula barne. Windowsen, Find-NetRoute -RemoteIPAddress 10.20.5.9 hautatutako bidea eta iturburu-helbidea itzultzen ditu, eta Get-NetRoute taula gordina erakusten du — baina kostu eraginkorra bidearen metrika gehi interfazearen metrika da, beraz adaptagailu geldo batek irabazten duela dirudien berdinketa gal dezake.

Hiru kasuk estaltzen dute ikusiko duzunaren zatirik handiena:

• Helmuga bera, /24 versus /0: /24-k prefijo-luzeran irabazten du, metrikek esaten dutena esanda ere.
• Helmuga bera, metrika ezberdineko bi /24: metrika eraginkor baxuena irabazten du.
• Helmuga bera, bi taula, bat politika-arau batek hautatua: arauak taula hautatzen du lehenengo, eta prefijo-konparaketa haren barruan gertatzen da.

Hirugarren kasua da txosten horien gehiengoa amaitzen den lekua. Linuxeko ip rule batek edo Windowsen VPN trafiko-iragazki batek inoiz tunelaren lehenetsitakoa eduki ez zuen taula batera bidal dezake trafikoa, eta taula nagusiak ezin hobea dirudi une oro.

Nork du normalean saihesbidearen jabea

Hasi profiletik, ez taulatik. Split-tunnel konfigurazioek eta aplikazioko VPN ezarpenek nahita uzten dituzte izendatutako prefijoak tunelaz kanpo; azpisare pribatu bat babesten duen eta nabigazio orokorra zuzenean joaten uzten duen lan-profilek diseinatu zen bezala jokatzen du, eta hura gainidazteak betearazi behar zuen politika hausten du. Microsoften VPN bideratzeko gida ardatz berak marrazten ditu tunelera behartutako trafikoaren eta salbuespen esplizituen artean, eta horrek edozer editatu aurretik egiaztapen gurutzatu erabilgarria bihurtzen du.

Ondoren, bilatu hondarrak. Jada existitzen ez den interfaze batera edo aurreko sareko helbide batera seinalatzen duen bidea agertzen da atrakatze-estazioak, USB adaptagailuak eta kontenedore-zubiak joan eta etorri ondoren. Behin ezabatzea ez da amaiera: NetworkManager konexio-profilek, netplan fitxategiek eta Windowsen bide iraunkorrek hurrengo konexioan edo abioan berriro instalatzen dute, beraz aurkitu hura duen fitxategia edo profila edozer editatu aurretik.

Ondoren egiaztatu IPv6 bere aldetik. ip -6 route eta Get-NetRoute -AddressFamily IPv6 egoera bereizia, lehenetsitako bide bereiziak eta bezero-portaera bereizia dituzte. IPv4 bakarrik aztertzeak ezer ez dio esaten IPv6 bide natibo bat isil-isilik nahiago duen pila bikoitzeko host bati, eta horrek bakarrik bezero bat split-tunnel itxura izatea eragin dezake.

Berretsi aplikazioaren beraren fluxuarekin

Idatzi aplikazioak benetan erabiltzen duen helmuga, eta gero galdetu sistemari aplikazio horrek lotzen duen iturburu-helbidetik hartuko lukeen bidea. ip route get 10.20.5.9 from 192.168.1.40 horri erantzuten dio Linuxen; Find-NetRoute -RemoteIPAddress 10.20.5.9 gehi helbide lokalak Windowsen egiten du. Konparatu emaitza profilek dioenarekin. Nabigatzaile baten IP publikoaren orriak helmuga bat probatzen du protokolo bakarrean, eta kexa hasi zuen helbide pribatuari buruz ezer ez du esaten.

Konpondu aldea azaltzen duen objektu estuena. Salbuespena onartuta badago, idatzi prefijoa eta utzi horrela; ez badago, kendu bidea edo gehitu tunelaren bidezko bide estuago esplizitu bat lehenetsitakoaren metrika jaistearen ordez. Metrika jaisteak ezin dio prefijo luzeago bati gailendu, eta lehenetsitakoa editatzeak, bi /1 bidek interneteko bidea duten bitartean, ez du ezer aldatzen.

Ondoren berriro konektatu tunela eta errepikatu kontsulta bera. Bezeroek konexio bakoitzean berriro instalatzen dituzte bideak, beraz hurrengo handshakeraino baino irauten ez duen aldaketa ez da probatu. Bidea oraindik desbideratzen bada, gainerako susmagarriak politika-arau bat, bigarren taula bat edo bezero-aldeko iragazki bat dira — ez lehenetsitako bidea.

• Aipa aplikazioak benetan erabiltzen dituen helmuga eta iturburu-helbidea.
• Erakutsi irabazteko bidea ip route get edo Find-NetRoute erabiliz.
• Egiaztatu /1 bikote batek edo politika-taula batek duen interneteko bidea.
• Zerrendatu helmugarekin bat egiten duen /0 baino luzeagoa den prefijo bakoitza.
• Errepikatu IPv6 egiaztapena bere aldetik.
• Jarraitu bizirik dagoen bidea hura instalatzen duen fitxategira, profilera edo iragazkira.
• Berriro konektatu eta exekutatu kontsulta berriro konpondutakotzat jo aurretik.

Zazpiek profilearekin bat egiten badute, tunelak konfiguratu zen zehazki egiten du, eta konponketa profilean dago, ez metrikan.