Dokumentace rozděleného tunelu potřebuje pravidlo DNS u každé trasy
Trasa rozhoduje podle adresy, resolver podle jména. Zdokumentujte oba selektory pro každý tok, každý s jedním testem, jinak poznámka selže, když se DNS posune.
Poznámka o rozděleném tunelu, která říká "kancelářský provoz jde přes VPN", zdokumentovala jedno rozhodnutí a tři další implikovala. Na vrstvě paketů směrovací tabulka vybírá rozhraní podle cílové adresy; na vrstvě jmen resolver vybírá server podle dotazu a tato dvě rozhodnutí se dělají nezávisle. Proto správně zdokumentovaný prefix může stále vytvořit stroj, který přeloží interní jméno na veřejnou adresu, nebo nepřeloží nic, zatímco trasa vypadá dokonale.
Dva selektory, jeden pokus o spojení
Když se aplikace připojí k files.corp.example, než paket vznikne, proběhnou dvě vyhledávání. Resolver rozhoduje, který server dotaz dostane, pomocí vyhledávacích domén, směrovacích domén pro každé spojení nebo explicitního pravidla profilu. Směrovací tabulka pak rozhoduje, kam výsledná adresa půjde, pomocí nejdelší shody prefixu s cílem.
Nic tato dvě rozhodnutí nespojuje. Privátní zóna může odpovědět 10.20.4.11 zatímco směrovací tabulka posílá 10.20.0.0/16 do tunelu, a spojení funguje. Otočte kterékoli z nich a selže způsobem, který vypadá jako to druhé: správná politika DNS plus chybějící trasa dává přeložené jméno a časový limit, zatímco správná trasa plus veřejný resolver dává adresu, která se čistě směruje na špatné místo.
DNS s rozděleným horizontem to zostřuje. Stejné jméno může vrátit privátní adresu z interního resolveru a veřejnou adresu z toho obráceného k internetu, takže poznámka, která zaznamenává jen prefix, nemůže předpovědět, kterou adresu klient skutečně použije. Zapište cestu resolveru, jinak je adresa odhad.
Co poznámka jen o trase vynechává
Záznam jen o trase je nepoužitelný pro nejčastější selhání rozděleného tunelu: jména. Uživatel hlásí, že se intranet nenačítá, tunel je nahoře a prefix existuje. Ten, kdo tiket převezme, nemá záznam o tom, který resolver měl odpovědět, nemá jak rozeznat špatný vyhledávací suffix od blokovaného serveru a nemá výchozí hodnotu pro srovnání.
Druhým vynecháním je seznam výjimek. Návrh rozděleného tunelu je definován stejně tím, co zůstává mimo tunel, jako tím, co do něj vstupuje, a vyloučené rozsahy se obvykle rozbijí první, protože specifičtější lokální trasa nebo filtr na straně klienta může záměr přebít, aniž by se dotkl profilu.
Třetí je vzdálená strana tunelu. Klientská trasa jen položí paket na drát; brána ho stále musí předávat a mít cestu zpět. strongSwanův návod k předávání připomíná, že pravidla předávání a firewallu na bráně jsou součástí funkce, ne součástí instalatérství, které lze předpokládat.
Pole, která činí poznámku vykonatelnou
Jeden řádek na tok, a tok je cíl plus jméno plus vlastník. To jsou pole, která přežijí střet s reálným incidentem:
| 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 |
Řádek "kde to žije" je ten, který lidé přeskakují. Prefix vnucený serverem, trasa přidaná klientským profilem a trasa napsaná do shellu se liší v tom, kdo je může změnit a zda přežijí opětovné připojení. Bez tohoto pole následující inženýr nepozná, na kterou ze tří se dívá.
Jeden test na pravidlo, ne na tunel
Každý řádek potřebuje dvě neškodné kontroly: jednu, která procvičí trasu, a jednu, která procvičí jméno. Pro trasu si vyžádejte něco, co musí projít tunelem, a potvrďte cestu, ne dosažitelnost, například tracert -d 10.20.4.11 na Windows nebo ip route get 10.20.4.11 na Linuxu. Pro jméno se dotážete na privátní jméno a zaznamenejte, který server odpověděl, pomocí resolvectl query files.corp.example nebo dig files.corp.example proti resolveru, který poznámka uvádí.
Přidejte i negativní očekávání: co se má stát, když je tunel dole. Vyloučená aplikace na zařízení Android nebo iOS se zapnutým blokováním bez VPN nemusí mít vůbec žádné připojení a desktopový klient může nechat stejnou aplikaci fungovat, zatímco se tunel znovu připojuje. Zaznamenání zamýšlené odpovědi mění "VPN mi rozbila aplikaci" na ověřitelné tvrzení.
Uchovávejte záznam s konfigurací
Uložte poznámku vedle profilu, který popisuje, a verzujte ji s tímto profilem. Dokument na wiki, který nikdo neaktualizuje, je drb; tabulka ve stejném repozitáři jako vnucené trasy a politika resolveru může být zkontrolována ve stejné změně.
Když se něco rozbije, porovnejte aplikovanou trasu a efektivní resolver se záznamem, než přidáte další výjimku. Dvě ze tří častých příčin — staré pravidlo jmenného prostoru a pomocný proces mimo politiku aplikace — vypadají přesně jako porucha VPN a jsou neviditelné, pokud poznámka uvádí jen prefixy.
Než poznámku prohlásíte za hotovou, potvrďte, že písemně odpovídá na toto: který prefix, pro kterou rodinu adres; který privátní jmenný prostor, kterým resolverem odpovězený; která jména zůstávají záměrně veřejná; kde je každé pravidlo nakonfigurováno a kdo je vlastní; a jediný příkaz, který dokazuje trasu, a ten, který dokazuje jméno. Pokud některé chybí, další incident bude diagnostikován od nuly.