Kailangan ng dokumentasyon ng split-tunnel ang DNS rule sa tabi ng bawat ruta
Ang ruta ay nagpapasya sa address, ang resolver ay nagpapasya sa pangalan. Idokumento ang dalawang selector bawat daloy, bawat isa ay may isang pagsubok, kung hindi ay mabibigo ang tala kapag gumalaw ang DNS.
Ang isang tala ng split-tunnel na nagsasabing "dumadaan sa VPN ang trapiko ng opisina" ay nagdokumento ng isang desisyon at nagpahiwatig ng tatlo pa. Sa antas ng packet, pinipili ng routing table ang isang interface ayon sa destinasyong address; sa antas ng pangalan, pinipili ng resolver ang isang server ayon sa query, at ang dalawang pagpili ay ginagawa nang hiwalay. Iyon ang dahilan kung bakit ang wastong naidokumentong prefix ay makakagawa pa rin ng makina na niresolba ang panloob na pangalan sa pampublikong address, o wala man lang niresolba habang perpekto ang hitsura ng ruta.
Dalawang selector, isang pagtatangkang kumonekta
Kapag kumonekta ang isang aplikasyon sa files.corp.example, may dalawang paghahanap bago magkaroon ng packet. Pinapasya ng resolver kung aling server ang tatanggap ng query, gamit ang mga search domain, routing domain bawat link o tahasang patakaran ng profile. Pagkatapos ay pinapasya ng routing table kung saan pupunta ang resultang address, gamit ang pinakamahabang tugma ng prefix sa destinasyon.
Walang nag-uugnay sa dalawang desisyong iyon. Maaaring sumagot ang isang pribadong zone ng 10.20.4.11, habang ipinapadala ng routing table ang 10.20.0.0/16 papasok sa tunnel, at gumagana ang koneksyon. Baliktarin ang alinman at mabibigo ito sa paraang mukhang ang isa pa: tamang patakaran ng DNS at kulang na ruta ay nagbibigay ng naresolbang pangalan at timeout, habang tamang ruta at pampublikong resolver ay nagbibigay ng address na malinis na niruruta sa maling lugar.
Pinapatalas ito ng split-horizon DNS. Maaaring ibalik ng parehong pangalan ang pribadong address mula sa panloob na resolver at pampublikong address mula sa nakaharap sa internet, kaya ang talang nagtatala lamang ng prefix ay hindi mahuhulaan kung aling address ang aktuwal na gagamitin ng kliyente. Isulat ang landas ng resolver o ang address ay isang haka-haka.
Ano ang iniiwan ng talang ruta lamang
Ang talaan na ruta lamang ay walang silbi sa pinakakaraniwang pagkabigo ng split-tunnel: mga pangalan. Iniulat ng user na hindi naglo-load ang intranet, nakataas ang tunnel at naroon ang prefix. Ang kukuha ng ticket ay walang talaan kung aling resolver ang dapat sumagot, walang paraan upang makilala ang maling search suffix sa isang naka-block na server, at walang baseline na paghahambingan.
Ang ikalawang pagkukulang ay ang listahan ng mga eksepsyon. Ang disenyo ng split-tunnel ay tinutukoy kasing dami ng nananatili sa labas ng tunnel at ng pumapasok dito, at ang mga ibinukod na saklaw ang karaniwang unang nasisira, dahil ang mas espesipikong lokal na ruta o filter sa panig ng kliyente ay maaaring madaig ang layunin nang hindi hinahawakan ang profile.
Ang ikatlo ay ang malayong panig ng tunnel. Ang ruta ng kliyente ay naglalagay lamang ng packet sa kawad; kailangan pa rin itong ipasa ng gateway at magkaroon ng daan pabalik. Ang gabay sa pagpapasa ng strongSwan ay nagpapaalala na ang mga patakaran sa pagpapasa at firewall sa gateway ay bahagi ng feature, hindi bahagi ng plumbing na maaari mong ipagpalagay.
Ang mga field na nagpapaging-maipapatupad sa tala
Isang hilera bawat daloy, at ang daloy ay destinasyon dagdag pangalan dagdag may-ari. Ito ang mga field na nakakaligtas sa pakikipagtagpo sa tunay na insidente:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
Ang hilerang "saan ito nakatira" ang nilalaktawan ng mga tao. Ang prefix na itinutulak ng server, rutang idinagdag ng profile ng kliyente at rutang tinipa sa shell ay nagkakaiba sa kung sino ang makakapagbago sa kanila at kung nakakaligtas sila sa muling pagkonekta. Kung wala ang field na iyon, hindi masasabi ng susunod na inhinyero kung alin sa tatlo ang tinitingnan niya.
Isang pagsubok bawat patakaran, hindi isa bawat tunnel
Kailangan ng bawat hilera ng dalawang walang-pinsalang pagsusuri: isa na nagsasanay sa ruta at isa na nagsasanay sa pangalan. Para sa ruta, humiling ng isang bagay na dapat tumawid sa tunnel at tiyakin ang landas sa halip na ang maabot, halimbawa tracert -d 10.20.4.11 sa Windows o ip route get 10.20.4.11 sa Linux. Para sa pangalan, itanong ang pribadong pangalan at itala kung aling server ang sumagot, gamit ang resolvectl query files.corp.example o dig files.corp.example laban sa resolver na pinangalanan ng tala.
Magdagdag din ng negatibong inaasahan: ano ang dapat mangyari kapag nakababa ang tunnel. Ang isang ibinukod na aplikasyon sa Android o iOS na may naka-enable na pagblock nang walang VPN ay maaaring walang koneksyon, at ang desktop client ay maaaring hayaang gumana ang parehong app habang muling kumokonekta ang tunnel. Ang pagtatala ng inaasahang sagot ay ginagawang masusuri na pahayag ang "sinira ng VPN ang app ko".
Itago ang tala kasama ng configuration
Itabi ang tala sa tabi ng profile na inilalarawan nito at i-version ito kasama ng profile na iyon. Ang dokumento sa wiki na walang nag-a-update ay tsismis; ang talahanayan sa parehong repository ng mga itinulak na ruta at patakaran ng resolver ay masusuri sa parehong pagbabago.
Kapag may nasira, ihambing ang inilapat na ruta at epektibong resolver sa tala bago magdagdag ng isa pang eksepsyon. Dalawa sa tatlong karaniwang dahilan — lumang patakaran ng namespace at helper process sa labas ng patakaran ng app — ay eksaktong mukhang sira ng VPN at hindi nakikita kung ang tala ay naglilista lamang ng mga prefix.
Bago sabihing tapos ang tala, tiyakin na sinasagot nito nang nakasulat ang mga ito: aling prefix, para sa aling pamilya ng address; aling pribadong namespace, sinagot ng aling resolver; aling mga pangalan ang sadyang nananatiling pampubliko; saan naka-configure ang bawat patakaran at sino ang may-ari; at ang nag-iisang command na nagpapatunay sa ruta at ang nagpapatunay sa pangalan. Kung may kulang sa mga ito, ang susunod na insidente ay madi-diagnose mula sa simula.