Dokumentaro pri split-tunnel bezonas DNS-regulon apud ĉiu vojo
Vojo decidas laŭ adreso, solvilo decidas laŭ nomo. Dokumentu ambaŭ elektilojn por ĉiu fluo, ĉiun kun unu provo, alie la noto malsukcesos kiam DNS moviĝos.
Noto pri split-tunnel kiu diras "ofica trafiko iras tra la VPN" dokumentis unu decidon kaj implicite tri aliajn. Ĉe la paka tavolo, enkursiga tabelo elektas interfacon laŭ cela adreso; ĉe la nomtavolo, solvilo elektas servilon laŭ peto, kaj la du elektoj fariĝas sendepende. Tial ĝuste dokumentita prefikso ankoraŭ povas produkti maŝinon kiu solvas internan nomon al publika adreso, aŭ solvas nenion dum la vojo aspektas perfekta.
Du elektiloj, unu provo de konekto
Kiam aplikaĵo konektiĝas al files.corp.example, du serĉoj okazas antaŭ ol ekzistas paketo. La solvilo decidas kiun servilon ricevos la peton, uzante serĉajn domajnojn, enkursigajn domajnojn por ligilo aŭ eksplicitan regulon de profilo. La enkursiga tabelo poste decidas kien iras la rezulta adreso, uzante la plej longan prefiksan kongruon kun la celo.
Nenio ligas tiujn du decidojn. Privata zono povas respondi per 10.20.4.11 dum la enkursiga tabelo sendas 10.20.0.0/16 en la tunelon, kaj la konekto funkcias. Turnu iun ajn el la du kaj ĝi malsukcesas tiel ke ĝi aspektas kiel la alia: ĝusta DNS-politiko plus mankanta vojo donas solvitan nomon kaj tempolimon, dum ĝusta vojo plus publika solvilo donas adreson kiu pure enkursiĝas al la malĝusta loko.
DNS de dividita horizonto faras tion pli akra. La sama nomo povas redoni privatan adreson de la interna solvilo kaj publikan adreson de la interreta, do noto kiu registras nur la prefikson ne povas antaŭdiri kiun adreson la kliento efektive uzos. Skribu la vojon de la solvilo aŭ la adreso estas konjekto.
Kion noto nur pri vojo preterlasas
Rikordo nur pri vojo estas senutila por la plej ofta fiasko de split-tunnel: nomoj. La uzanto raportas ke la intraneto ne ŝargiĝas, la tunelo estas supre, kaj la prefikso ĉeestas. Kiu prenas la bileton havas neniun rikordon pri tio, kiu solvilo devus esti respondinta, neniun manieron distingi malĝustan serĉan sufikson de blokita servilo, kaj neniun bazlinion por kompari.
La dua preterlaso estas la listo de esceptoj. Dezajno de split-tunnel difiniĝas same per tio, kio restas ekster la tunelo, kiel per tio, kio eniras ĝin, kaj la ekskluditaj gamoj estas kutime la unuaj kiuj rompiĝas, ĉar pli specifa loka vojo aŭ filtrilo ĉe la kliento povas superregi la intencon sen tuŝi la profilon.
La tria estas la malproksima flanko de la tunelo. Klienta vojo nur metas la paketon sur la draton; la kluzo ankoraŭ devas plusendi ĝin kaj havi revenan vojon. La gvidilo pri plusendado de strongSwan memorigas ke plusendaj kaj fajroŝirmaj reguloj ĉe la kluzo estas parto de la funkcio, ne parto de la plumbado kiun vi povas supozi.
La kampoj kiuj igas la noton plenumebla
Unu vico por fluo, kaj fluo estas celo plus nomo plus posedanto. Jen la kampoj kiuj postvivas renkonton kun reala okazaĵo:
| 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 |
La vico "kie ĝi loĝas" estas la sola kiun homoj preterlasas. Prefikso puŝita de la servilo, vojo aldonita de klienta profilo kaj vojo tajpita en ŝelon diferencas laŭ tio, kiu povas ŝanĝi ilin kaj ĉu ili postvivas rekonekton. Sen tiu kampo, la sekva inĝeniero ne povas diri kiun el la tri li rigardas.
Unu provo por regulo, ne unu por tunelo
Ĉiu vico bezonas du sendanĝerajn kontrolojn: unu kiu ekzercas la vojon kaj unu kiu ekzercas la nomon. Por la vojo, petu ion kio devas transiri la tunelon kaj konfirmu la vojon anstataŭ la atingeblon, ekzemple tracert -d 10.20.4.11 en Windows aŭ ip route get 10.20.4.11 en Linux. Por la nomo, petu la privatan nomon kaj registru kiu servilo respondis, uzante resolvectl query files.corp.example aŭ dig files.corp.example kontraŭ la solvilo kiun la noto nomas.
Aldonu ankaŭ negativan atendojn: kio devus okazi kiam la tunelo estas malsupre. Ekskludita aplikaĵo sur Android aŭ iOS-aparato kun blokado sen VPN ŝaltita eble havas tute neniun konekton, kaj labortabla kliento povas lasi la saman aplikaĵon funkcii dum la tunelo rekonektiĝas. Registri la celatan respondon transformas "la VPN rompis mian aplikaĵon" en kontroleblan aserton.
Tenadu la rikordon kun la agordo
Konservu la noton apud la profilo kiun ĝi priskribas kaj versiigu ĝin kun tiu profilo. Dokumento en vikio kiun neniu ĝisdatigas estas onidiro; tabelo en la sama deponejo kiel la puŝitaj vojoj kaj la solvila politiko povas esti reviziita en la sama ŝanĝo.
Kiam io rompiĝas, komparu la aplikitan vojon kaj la efektivan solvilon kun la rikordo antaŭ ol aldoni alian escepton. Du el la tri oftaj kaŭzoj — malnova regulo de nomspaco kaj helpproceso ekster la aplikaĵa politiko — aspektas ĝuste kiel VPN-fiasko kaj estas nevideblaj se la noto listigas nur prefiksojn.
Antaŭ ol nomi la noton finita, konfirmu ke ĝi skribe respondas al ĉi tiuj: kiu prefikso, por kiu adresa familio; kiu privata nomspaco, respondita de kiu solvilo; kiuj nomoj intence restas publikaj; kie ĉiu regulo agordiĝas kaj kiu posedas ĝin; kaj la unu komando kiu pruvas la vojon kaj la unu kiu pruvas la nomon. Se io el tio mankas, la sekva okazaĵo estos diagnozita de nulo.