Kapag nag-o-overlap ang mga ruta ng split tunnel: aling prefix ang nananalo
Ang pagtutugma ng pinakamahabang prefix, metriko at mga tuntunin ng patakaran ang nagpapasya kung aling tunnel ang naglilingkod sa magkasanib na destinasyon. Suriin muna ang address ng pinagmulan at ang naresolba na pangalan.
Dalawang profile ng split tunnel, dalawang pribadong prefix at isang host na parehong inaangkin. Bihirang maging malinis na pagkabigo ang sintomas: gumagana ang isang serbisyo noong Lunes, nag-time out pagkatapos muling kumonekta ang pangalawang kliyente, at gumagana muli pagkatapos ng restart. Ang pagkakasunod-sunod ng pagkonekta sa mga kliyente ay hindi nagpapasya sa resulta, at gayundin ang pagkakasunod-sunod ng mga hilera sa interface ng kliyente. Isagawa ang mga pagsusuring ito nang sunod-sunod, at huminto sa unang hindi tumatayo, dahil ang mga susunod ay may saysay lamang kapag totoo ang mga nauna.
1. Isulat ang destinasyon at ang pinagmulan
Simulan sa eksaktong address na pinupuntahan ng nabigong kahilingan, hindi sa pangalan ng host at hindi sa pangalan ng aplikasyon. I-resolba ang pangalan nang isang beses, itala ang bawat sagot at piliin ang ginagamit talaga ng nabigong daloy. Pagkatapos itala ang lokal na address ng parehong daloy, dahil ang address ng pinagmulan ay maaaring magbago kung aling tuntunin ng patakaran ang tumutugma at kung gayon aling talahanayan ang tinitingnan.
Ang kahilingan sa isa sa maraming A record ay maaaring mabigo habang nagtatagumpay ang kapatid na address, na mukhang hindi matatag na tunnel ngunit talagang dalawang magkaibang landas. Kung ang destinasyon ay pangalang may maraming sagot, subukan ang bawat sagot nang hiwalay bago baguhin ang anuman.
2. Tanungin ang kernel kung aling ruta ang pinili nito
Huwag basahin ang talahanayan ng ruta at huwag hulaan ang sagot. Itanong ang parehong tanong na itinatanong ng stack, gamit ang parehong address ng pinagmulan: ip route get 10.20.4.10 from 10.8.0.2 sa Linux, o Find-NetRoute -RemoteIPAddress 10.20.4.10 sa PowerShell. Pinapangalanan ng output ang rutang talagang gagamitin, at madalas ito ay hindi ang inaasahan mo nang binabasa ang talahanayan.
Sa mga rutang tumutugma, karaniwang nananalo ang mas tiyak na prefix: ang /24 ay tumatalo sa /16 para sa address na nasa pareho. Sa pagitan ng magkatugmang magkapareho ang haba, nananalo ang mas mababang metriko, at ang rutang naka-install sa link na down ay nilalaktawan. Ang dalawang tunnel na nagtutulak ng parehong /24 na may parehong metriko ay ibang kaso: pinapanatili ng kernel ang dalawang ruta at pumipili sa pagitan ng mga ito, kaya maaaring magpalit-palit ang resulta sa halip na sumunod sa pagkakasunod-sunod ng pagkonekta ng mga kliyente. Ito mismo ang sitwasyong gumagawa ng pattern na Lunes-gumagana-Martes-bumabagsak, at hindi ito binabago ng muling pagkonekta sa ibang pagkakasunod-sunod.
3. Suriin kung may tuntunin ng patakaran na naglihis sa paghahanap
Bago tingnan ang talahanayan ng ruta, dumadaan ang kernel sa mga tuntunin ng patakaran nito. Maaaring ipadala ng isang tuntunin ang trapiko mula sa isang partikular na pinagmulan, gumagamit o marka ng firewall patungo sa ganap na ibang talahanayan, kaya maaaring hindi kailanman tingnan ang nananalong prefix sa pangunahing talahanayan para sa daloy na iyon. Inililista ng ip rule show ang mga ito sa pagkakasunod-sunod ng pagsusuri, at ipinapakita ng ip route show table 100 kung ano talaga ang nilalaman ng piniling talahanayan.
May dalawang bitag dito. Ang tuntuning tumuturo sa walang laman na talahanayan ay gumagawa ng paghahanap na nahuhulog sa susunod na tuntunin, kaya mukhang wala itong ginagawa. Ang isa pa ay ang bilang ng priyoridad mismo: binabasa ang mga tuntunin sa pataas na pagkakasunod-sunod, at ang mga built-in na halaga ay 0 local, 32766 main at 32767 default. Ang tuntuning may bilang na mas mababa sa 32767 ay tinitingnan bago ang default na tuntuning humuhuli sa lahat. Ang tuntuning may bilang na mas mataas sa 32767 ay nasa likod nito at naaabot lamang kapag walang naunang talahanayang sumagot, na hinahadlangan ng ordinaryong default na ruta sa main, kaya sa praktika hindi ito naaabot at tahimik na walang ginagawa habang mukhang naka-install. Kung nagsulat ang kliyente ng tuntunin at ruta, suriin ang pareho, at suriin muli pagkatapos ng muling pagkonekta, dahil ang muling isinulat na profile ay maaaring magdagdag ng pangalawang tuntunin na may ibang priyoridad.
4. Ihiwalay ang tabla ng ruta sa doble ang plano ng address
Minsan ang prefix ay hindi talaga ang problema. Dalawang site na parehong gumagamit ng 192.168.1.0/24 ay nangangahulugang ang parehong address ay tumutukoy sa dalawang magkaibang host, at walang rutang makakapaghiwalay sa kanila. Ang rutang host patungo sa isa sa dalawang sagot ay gumagana lamang hanggang sumagot ang kabilang site para sa parehong pangalan, at pagkatapos ay tahimik na nagiging mismong depekto ang eksepsiyon.
Ang palatandaan ay magkapareho ang address ng destinasyon sa dalawang landas at ang tanging naiiba ay ang inaasahang may-ari. Ito ay desisyon sa plano ng address, hindi pagsasaayos ng pagruruta: muling bilangin ang isang panig, ilagay ang isang panig sa likod ng gateway na nagsasalin, o abutin ang pangalawang site sa pamamagitan ng proxy na mismo ang nagre-resolba ng mga pangalan nito. Ang pagbaba ng default na ruta o pagtatambak ng eksepsiyon ng host ay naglilipat lamang ng banggaan.
5. Tiyakin na sumasang-ayon ang resolver sa ruta
Ang pangalang naresolba sa maling pribadong address ay gumagawa ng lahat ng sintomas ng hidwaan sa pagruruta at wala sa mga sanhi nito. Ihambing ang sagot na natatanggap ng host sa address na talagang ginagamit ng destinasyon, at suriin kung aling resolver ang sumagot. Kung nagtutulak ang tunnel ng resolver, dapat itong i-install ng kliyente para sa mga daloy na gumagamit ng tunnel; kung hindi, patuloy na nagtatanong ang host sa lokal na resolver, na maaaring sumagot mula sa search domain o sa naka-cache na record.
Tanungin nang direkta ang resolver at itala ang server na sumagot. Ang naka-cache na sagot na may maikling TTL ay maaari ring magpaliwanag kung bakit ang unang kahilingan pagkatapos ng muling pagkonekta ay kakaiba sa ikalima.
6. Muling kumonekta, siyasatin ang inilapat na estado, pagkatapos ay subukan ang dalawang daloy
Pagkatapos ng pagwawasto, muling kumonekta at siyasatin kung ano talaga ang in-install ng kliyente sa halip na magtiwala sa editor ng profile. Basahin muli ang mga tuntunin, talahanayan at ang resultang sagot ng ip route get. Ang pangalawang kliyente ay maaaring muling mag-install ng sarili nitong ruta kapag kumonekta at muling likhain ang hidwaan, kaya ang pagsusuri ng estado ay dapat mangyari pagkatapos kumonekta ang huling kliyente, hindi bago.
Subukan ang dalawang daloy, hindi isa: ang kahilingang dating nabibigo, at ang resource na dapat gumamit ng kabilang tunnel. Ang ilipat ang lahat ng pribadong trapiko sa isang koneksiyon ay magpapapasa sa unang pagsubok habang sinisira ang pangalawa, at tanging pares na pagsubok ang makakahuli niyon. Itala ang bawat eksepsiyong iniingatan mo, kasama ang destinasyon at dahilan, upang ang susunod na tao ay makilala ang sinadyang rutang host mula sa natira.