Dokumentácia split-tunnelu potrebuje pravidlo DNS pri každej trase
Trasa rozhoduje podľa adresy, resolver podľa mena. Zdokumentujte oba selektory pre každý tok, každý s jedným testom, inak poznámka zlyhá, keď sa DNS posunie.
Poznámka o split-tunneli, ktorá hovorí "kancelárska prevádzka ide cez VPN", zdokumentovala jedno rozhodnutie a naznačila tri ďalšie. Na vrstve paketov smerovacia tabuľka vyberá rozhranie podľa cieľovej adresy; na vrstve mien resolver vyberá server podľa dotazu a tieto dve voľby sa robia nezávisle. Preto správne zdokumentovaný prefix môže stále vytvoriť stroj, ktorý preloží interné meno na verejnú adresu, alebo nepreloží nič, kým trasa vyzerá dokonale.
Dva selektory, jeden pokus o spojenie
Keď sa aplikácia pripojí k files.corp.example, pred vznikom paketu prebehnú dve vyhľadávania. Resolver rozhoduje, ktorý server dostane dotaz, pomocou vyhľadávacích domén, smerovacích domén pre každé spojenie alebo explicitného pravidla profilu. Smerovacia tabuľka potom rozhoduje, kam pôjde výsledná adresa, pomocou najdlhšej zhody prefixu s cieľom.
Nič tieto dve rozhodnutia nespája. Privátna zóna môže odpovedať 10.20.4.11, kým smerovacia tabuľka posiela 10.20.0.0/16 do tunela, a spojenie funguje. Otočte ktorékoľvek a zlyhá spôsobom, ktorý vyzerá ako to druhé: správna politika DNS plus chýbajúca trasa dáva preložené meno a časový limit, kým správna trasa plus verejný resolver dáva adresu, ktorá sa čisto smeruje na nesprávne miesto.
DNS s rozdeleným horizontom to zostruje. To isté meno môže vrátiť privátnu adresu z interného resolvera a verejnú adresu z toho obráteného k internetu, takže poznámka, ktorá zaznamenáva len prefix, nemôže predpovedať, ktorú adresu klient skutočne použije. Zapíšte cestu resolvera, inak je adresa odhad.
Čo poznámka len o trase vynecháva
Záznam len o trase je nepoužiteľný pre najčastejšie zlyhanie split-tunnelu: mená. Používateľ hlási, že sa intranet nenačítava, tunel je hore a prefix existuje. Ten, kto prevezme tiket, nemá záznam o tom, ktorý resolver mal odpovedať, nemá ako rozlíšiť nesprávnu vyhľadávaciu príponu od blokovaného servera a nemá východiskovú hodnotu na porovnanie.
Druhým vynechaním je zoznam výnimiek. Návrh split-tunnelu je definovaný rovnako tým, čo zostáva mimo tunela, ako tým, čo doň vstupuje, a vylúčené rozsahy sa zvyčajne rozbijú prvé, pretože konkrétnejšia lokálna trasa alebo filter na strane klienta môže zámer prebiť bez dotknutia profilu.
Tretia je vzdialená strana tunela. Klientska trasa len položí paket na drôt; brána ho stále musí preposielať a mať cestu späť. Návod strongSwan k preposielaniu pripomína, že pravidlá preposielania a firewallu na bráne sú súčasťou funkcie, nie súčasťou inštalatérstva, ktoré možno predpokladať.
Polia, ktoré robia poznámku vykonateľnou
Jeden riadok na tok, a tok je cieľ plus meno plus vlastník. Toto sú polia, ktoré prežijú stretnutie s reálnym incidentom:
| 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 |
Riadok "kde to žije" je ten, ktorý ľudia preskakujú. Prefix vnútený serverom, trasa pridaná klientskym profilom a trasa napísaná do shellu sa líšia tým, kto ich môže zmeniť a či prežijú opätovné pripojenie. Bez tohto poľa nasledujúci inžinier nevie, na ktorú z troch sa pozerá.
Jeden test na pravidlo, nie na tunel
Každý riadok potrebuje dve neškodné kontroly: jednu, ktorá precvičí trasu, a jednu, ktorá precvičí meno. Pre trasu požiadajte o niečo, čo musí prejsť tunelom, a potvrďte cestu, nie dostupnosť, napríklad tracert -d 10.20.4.11 v Windows alebo ip route get 10.20.4.11 v Linuxe. Pre meno sa opýtajte na privátne meno a zaznamenajte, ktorý server odpovedal, pomocou resolvectl query files.corp.example alebo dig files.corp.example proti resolveru, ktorý poznámka uvádza.
Pridajte aj negatívne očakávanie: čo sa má stať, keď je tunel dole. Vylúčená aplikácia na zariadení Android alebo iOS so zapnutým blokovaním bez VPN nemusí mať vôbec žiadne pripojenie a desktopový klient môže nechať tú istú aplikáciu fungovať, kým sa tunel znova pripája. Zaznamenanie zamýšľanej odpovede mení "VPN mi rozbila aplikáciu" na overiteľné tvrdenie.
Uchovávajte záznam s konfiguráciou
Uložte poznámku vedľa profilu, ktorý opisuje, a verzujte ju s týmto profilom. Dokument na wiki, ktorý nikto neaktualizuje, je klebeta; tabuľka v tom istom úložisku ako vnútené trasy a politika resolvera sa dá skontrolovať v tej istej zmene.
Keď sa niečo pokazí, porovnajte aplikovanú trasu a efektívny resolver so záznamom predtým, než pridáte ďalšiu výnimku. Dve z troch častých príčin — staré pravidlo menného priestoru a pomocný proces mimo politiky aplikácie — vyzerajú presne ako porucha VPN a sú neviditeľné, ak poznámka uvádza len prefixy.
Predtým než poznámku vyhlásite za hotovú, potvrďte, že písomne odpovedá na toto: ktorý prefix, pre ktorú rodinu adries; ktorý privátny menný priestor, ktorým resolverom odpovedaný; ktoré mená zámerne zostávajú verejné; kde je každé pravidlo nakonfigurované a kto ho vlastní; a jediný príkaz, ktorý dokazuje trasu, a ten, ktorý dokazuje meno. Ak niečo chýba, ďalší incident bude diagnostikovaný od nuly.