Dokumentacija razdvojenog tunela treba DNS pravilo uz svaku rutu
Ruta odlučuje po adresi, resolver po imenu. Dokumentirajte oba selektora za svaki tok, svaki s jednim testom, inače bilješka pada kad se DNS promijeni.
Bilješka o razdvojenom tunelu koja kaže "uredski promet ide kroz VPN" dokumentirala je jednu odluku i podrazumijevala tri druge. Na sloju paketa routing tablica bira interfejs po odredišnoj adresi; na sloju imena resolver bira server po upitu, a te dvije odluke donose se neovisno. Zato ispravno dokumentiran prefiks još uvijek može dati mašinu koja interno ime razrješava u javnu adresu, ili ne razrješava ništa dok ruta izgleda savršeno.
Dva selektora, jedan pokušaj veze
Kad se aplikacija poveže na files.corp.example, dvije pretrage dogode se prije nego što paket postoji. Resolver odlučuje koji server prima upit, koristeći domene pretrage, routing domene po vezi ili izričito pravilo profila. Routing tablica zatim odlučuje kamo ide dobivena adresa, koristeći najdulje podudaranje prefiksa s odredištem.
Ništa ne povezuje te dvije odluke. Privatna zona može odgovoriti s 10.20.4.11 dok routing tablica šalje 10.20.0.0/16 u tunel, i veza radi. Okrenite bilo koju i pada na način koji izgleda kao druga: ispravna DNS politika plus nedostajuća ruta daje razriješeno ime i istek vremena, a ispravna ruta plus javni resolver daje adresu koja se čisto usmjerava na pogrešno mjesto.
Split-horizon DNS čini to oštrijim. Isto ime može vratiti privatnu adresu od internog resolvera i javnu adresu od onog okrenutog internetu, pa bilješka koja bilježi samo prefiks ne može predvidjeti koju će adresu klijent stvarno koristiti. Zapišite put resolvera ili je adresa nagađanje.
Šta bilješka samo o ruti izostavlja
Zapis samo o ruti beskoristan je za najčešći kvar razdvojenog tunela: imena. Korisnik prijavljuje da se intranet ne učitava, tunel je podignut i prefiks postoji. Onaj ko preuzme tiket nema zapis koji je resolver trebao odgovoriti, nema način da razlikuje pogrešan sufiks pretrage od blokiranog servera i nema osnovicu za usporedbu.
Drugi izostanak je popis izuzetaka. Dizajn razdvojenog tunela određen je koliko onim što ostaje izvan tunela toliko i onim što u njega ulazi, a isključeni rasponi obično se prvi lome, jer konkretnija lokalna ruta ili filter na strani klijenta može nadjačati namjeru bez diranja profila.
Treći je daleka strana tunela. Klijentska ruta samo stavlja paket na žicu; gateway ga još mora prosljeđivati i imati povratni put. strongSwanov vodič za prosljeđivanje podsjetnik je da su pravila prosljeđivanja i vatrozida na gatewayu dio značajke, a ne dio vodovoda koji možete pretpostaviti.
Polja koja bilješku čine izvršivom
Jedan redak po toku, a tok je odredište plus ime plus vlasnik. Ovo su polja koja prežive susret sa stvarnim 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 |
Redak "gdje živi" je onaj koji ljudi preskaču. Prefiks koji gurne server, ruta koju doda klijentski profil i ruta utipkana u ljusku razlikuju se po tome ko ih može promijeniti i preživljavaju li ponovno spajanje. Bez tog polja sljedeći inženjer ne može reći koje od troje gleda.
Jedan test po pravilu, ne po tunelu
Svaki redak treba dvije bezopasne provjere: jednu koja vježba rutu i jednu koja vježba ime. Za rutu zatražite nešto što mora prijeći tunel i potvrdite put, a ne dosegljivost, na primjer tracert -d 10.20.4.11 na Windowsu ili ip route get 10.20.4.11 na Linuxu. Za ime upitajte privatno ime i zabilježite koji je server odgovorio, koristeći resolvectl query files.corp.example ili dig files.corp.example prema resolveru koji bilješka navodi.
Dodajte i negativno očekivanje: što se treba dogoditi kad je tunel pao. Izuzeta aplikacija na Android ili iOS uređaju s uključenim blokiranjem bez VPN-a možda nema nikakvu vezu, a desktop klijent može ostaviti istu aplikaciju radnom dok se tunel ponovno spaja. Bilježenje namjeravanog odgovora pretvara "VPN mi je slomio aplikaciju" u provjerljivu tvrdnju.
Čuvajte zapis uz konfiguraciju
Pohranite bilješku uz profil koji opisuje i verzionirajte je s tim profilom. Dokument na wikiju koji nitko ne ažurira jest glasina; tablica u istom repozitoriju kao gurane rute i politika resolvera može se pregledati u istoj izmjeni.
Kad se nešto slomi, usporedite primijenjenu rutu i efektivni resolver sa zapisom prije nego dodate još jedan izuzetak. Dva od tri česta uzroka — staro pravilo imenskog prostora i pomoćni proces izvan politike aplikacije — izgledaju točno kao kvar VPN-a i nevidljivi su ako bilješka navodi samo prefikse.
Prije nego bilješku proglasite gotovom, potvrdite da pisano odgovara na ovo: koji prefiks, za koju obitelj adresa; koji privatni imenski prostor, koji resolver odgovara; koja imena namjerno ostaju javna; gdje je svako pravilo konfigurirano i ko ga posjeduje; te jedna naredba koja dokazuje rutu i jedna koja dokazuje ime. Ako išta od toga nedostaje, sljedeći incident bit će dijagnosticiran od nule.