Bakit isang subnet pa rin ang lumalampas sa default na ruta ng iyong VPN

Inililipat mo ang VPN sa buong tunnel, sumusunod ang karamihan ng trapiko, at pagkatapos ay may isang address na direktang sumasagot — isang printer, isang NAS, isang jump host sa 10.x. Ang halatang pagbasa ay tumatagas ang tunnel, kaya binababa mo ang metric sa default na ruta at walang nagbabago. Ang nabigong pagtatangkang iyon ang bakas: ang default na ruta ay isang reserba, hindi isang hatol. Ang paghahanap ng ruta ay kumukuha ng pinakamahabang tugmang prefix bago pa man ihambing ang mga metric, kaya patuloy na nananalo ang /24 laban sa /0, anuman ang numerong ikabit mo sa alinman sa kanila. Kapag malinaw na ang pagkakasunod-sunod na iyon, ang pagtagas ay karaniwang isang rutang sadyang inilagay ng isang tao, o isang prefix na hindi kailanman sinadya ng kliyenteng saklawin.

Ano ang talagang ipinapangako ng default na ruta

Ang 0.0.0.0/0 ay tumutugma sa bawat destinasyong IPv4 na may sero bit na pagiging tiyak. Ito ay umiiral upang maabot ng host ang anumang hindi mas mahusay na inilalarawan ng kanyang talahanayan. Ang rutang patungo sa 192.168.1.0/24 ay nagdadala ng 24 na tugmang bit, kaya para sa 192.168.1.40 nananalo ito bago pa ihambing ng kahit sino ang mga metric, administratibong distansya o kung ano man ang itawag ng kliyente sa field ng priyoridad nito. Ang parehong tuntunin ay umiiral sa Linux FIB, sa routing table ng Windows at sa BSD stack sa likod ng macOS.

Sa isang normal na LAN, ang gawi na iyon ay isang katangian. Ang lokal na subnet ay direktang nakakabit, patuloy na gumagana ang printer habang dinadala ng tunnel ang iyong pag-browse, at walang mali ang pagkaka-configure. Ang tanong na dapat itanong ay hindi kung bakit direktang dumadaan ang isang address na iyon, kundi kung aling prefix sa aling talahanayan ang tumutugma rito, at sino ang naglagay nito roon.

Mga kalahating-default, o bakit maaaring mukhang hindi nagalaw ang default na entry

Ang pinakamalinis na halimbawa ay redirect-gateway def1 sa OpenVPN. Sa halip na tanggalin at palitan ang iyong default, nagdadagdag ito ng 0.0.0.0/1 at 128.0.0.0/1. Sama-samang sinasaklaw ng pares ang buong IPv4, mas mahaba ang bawat prefix kaysa /0, at parehong tinatalo ang default ng router habang pinapanatili ito sa lugar. Magpatakbo ng listahan ng ruta pagkatapos at ang orihinal na default ay nandoon pa rin, nakaturo pa rin sa iyong gateway; hindi lang ito kailanman pinipili para sa mga destinasyong internet.

Ang wg-quick ng WireGuard ay umabot sa parehong resulta sa pamamagitan ng routing na batay sa patakaran. Kapag sinasaklaw ng AllowedIPs ang 0.0.0.0/0, gumagawa ito ng sariling talahanayan, nagpapadala doon ng mga markadong packet, at nagdaragdag ng tuntuning bumabalewala sa prefix na may habang sero ng pangunahing talahanayan. Pinapanatili ng pangunahing talahanayan ang default na entry nito, at nagpapasya ang mga tuntunin na ang talahanayan ng tunnel ang unang kinukunsulta para sa trapikong pag-aari ng interface.

Ang parehong disenyo ay nangangailangan ng eksaktong isang ruta sa labas ng tunnel: isang host route patungo sa sariling address ng VPN server sa pamamagitan ng orihinal na gateway. Kung wala ito, susubukan ng kliyente na dalhin sa loob ng tunnel ang mga packet na bumubuo ng tunnel, at hindi kailanman makukumpleto ang koneksyon. Kaya ang isang rutang hindi tunnel sa iyong talahanayan ay normal kahit sa mahigpit na full-tunnel na profile. Ang mga rutang dapat tanungin ay ang mga sumasaklaw sa mga destinasyong talagang mahalaga sa iyo.

Ang metric ang nagpapasya sa tabla, ang prefix ang nagpapasya sa panalo

Ang mga metric ay ikinukumpara lamang sa mga kandidatong pantay na tumutugma sa destinasyon. Sa Linux ip route get 10.20.5.9 ipinapakita ang nanalo kasama ang kanyang talahanayan, at ip route show table all inililista ang mga kandidato, kasama ang anumang kalahating-default at anumang talahanayang itinuturo ng isang tuntunin. Sa Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 ibinabalik ang napiling ruta at ang source address, habang Get-NetRoute ipinapakita ang hilaw na talahanayan — pero ang epektibong gastos ay ruta metric dagdag interface metric, kaya ang mabagal na adapter ay maaaring matalo sa tabla na tila pinapanalunan niya.

Tatlong kaso ang sumasaklaw sa karamihan ng makikita mo:

• Parehong destinasyon, /24 laban sa /0: nananalo ang /24 sa haba ng prefix, ano man ang sabihin ng mga metric.
• Parehong destinasyon, dalawang /24 na may magkaibang metric: nananalo ang mas mababang epektibong metric.
• Parehong destinasyon, dalawang talahanayan, isa ang pinili ng tuntunin ng patakaran: pinipili muna ng tuntunin ang talahanayan, at doon nangyayari ang paghahambing ng prefix.

Ang ikatlong kaso ang kadalasang pinaghuhulugan ng karamihan ng mga ulat na ito. ip rule ng Linux o isang filter ng trapikong VPN ng Windows ay maaaring magpadala ng trapiko sa isang talahanayang hindi kailanman naglaman ng default ng tunnel, at ang pangunahing talahanayan ay mukhang perpekto sa lahat ng oras.

Sino ang karaniwang may-ari ng paglampas

Magsimula sa profile, hindi sa talahanayan. Ang mga split-tunnel na configuration at VPN settings kada app ay sadyang nag-iiwan ng mga pinangalanang prefix sa labas ng tunnel; ang isang work profile na nagpoprotekta sa isang pribadong subnet at nagpapabaya sa pangkalahatang pag-browse na dumiretso ay kumikilos ayon sa disenyo, at ang pag-override nito ay sisira sa patakarang dapat nitong ipatupad. Ang gabay sa routing ng VPN ng Microsoft ay gumuhit ng parehong linya sa pagitan ng sapilitang trapikong tunnel at mga tahasang pagbubukod, na ginagawa itong kapaki-pakinabang na cross-check bago ka mag-edit ng anuman.

Pagkatapos, maghanap ng mga labi. Ang rutang nakaturo sa isang interface na wala na, o sa isang address mula sa dating network, ay lumilitaw pagkatapos ng pagdating at pag-alis ng mga docking station, USB adapter at tulay ng container. Ang isang beses na pagtanggal ay hindi ang wakas: ang mga profile ng koneksyon ng NetworkManager, mga file ng netplan at mga persistenteng ruta ng Windows ay nag-i-install muli nito sa susunod na koneksyon o boot, kaya hanapin ang file o profile na may-ari nito bago ka mag-edit ng anuman.

Pagkatapos, suriin ang IPv6 nang hiwalay. ip -6 route at Get-NetRoute -AddressFamily IPv6 ay may hiwalay na estado, hiwalay na default at hiwalay na gawi ng kliyente. Ang audit na IPv4 lamang ay walang sinasabi tungkol sa isang dual-stack na host na tahimik na pinipili ang katutubong landas ng IPv6, at iyon lamang ay maaaring magpamukha sa isang kliyente na split-tunnel.

Kumpirmahin gamit ang sariling daloy ng aplikasyon

Itala ang destinasyong talagang ginagamit ng aplikasyon, pagkatapos ay tanungin ang sistema tungkol sa landas na tatahakin nito mula sa source address na kinabibitinan ng aplikasyong iyon. ip route get 10.20.5.9 from 192.168.1.40 ang sumasagot doon sa Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 dagdag ang lokal na address ang gumagawa niyon sa Windows. Ihambing ang resulta sa sinasabi ng profile. Ang pampublikong-IP na pahina ng browser ay sumusubok ng isang destinasyon sa isang protocol at walang sinasabi tungkol sa pribadong address na nagpasimula ng reklamo.

Ayusin ang pinakamakitid na bagay na nagpapaliwanag ng pagkakaiba. Kung aprubado ang pagbubukod, isulat ang prefix at pabayaan ito; kung hindi, alisin ang ruta o magdagdag ng tahasang mas makitid na ruta sa pamamagitan ng tunnel sa halip na babaan ang metric ng default. Ang pagbaba ng metric ay hindi makalalampas sa mas mahabang prefix, at ang pag-edit ng default habang dalawang rutang /1 ang may-ari ng landas ng internet ay wala ring binabago.

Pagkatapos, muling ikonekta ang tunnel at ulitin ang parehong query. Nag-i-install muli ang mga kliyente ng ruta sa bawat koneksyon, kaya ang pagbabagong tumatagal lamang hanggang sa susunod na handshake ay hindi pa nasubok. Kung nagkakaiba pa rin ang landas, ang natitirang mga suspek ay isang tuntunin ng patakaran, isang ikalawang talahanayan o isang filter sa panig ng kliyente — hindi ang default na ruta.

• Pangalanan ang destinasyon at ang source address na talagang ginagamit ng app.
• I-print ang nananalong ruta gamit ang ip route get o Find-NetRoute.
• Suriin kung ang pares na /1 o isang talahanayan ng patakaran ang may-ari ng landas ng internet.
• Ilista ang bawat prefix na mas mahaba sa /0 na tumutugma sa destinasyon.
• Ulitin ang pagsusuri ng IPv6 nang hiwalay.
• Sundan ang natitirang ruta pabalik sa file, profile o filter na nag-i-install nito.
• Muling kumonekta at muling patakbuhin ang query bago tawagin itong naayos.

Kung ang lahat ng pito ay sumasang-ayon sa profile, ginagawa ng tunnel ang eksaktong naka-configure para gawin, at ang pag-aayos ay nabibilang sa profile, hindi sa metric.