Dokumentacija razdeljenega tunela potrebuje pravilo DNS ob vsaki poti
Pot odloča po naslovu, razreševalnik odloča po imenu. Dokumentirajte oba selektorja za vsak tok, vsakega z enim testom, sicer opomba odpove, ko se DNS premakne.
Opomba o razdeljenem tunelu, ki pravi "pisarniški promet gre skozi VPN", je dokumentirala eno odločitev in nakazala tri druge. Na paketni ravni usmerjevalna tabela izbere vmesnik po ciljnem naslovu; na imenski ravni razreševalnik izbere strežnik po poizvedbi, in ti dve izbiri se naredita neodvisno. Zato lahko pravilno dokumentirana predpona še vedno ustvari stroj, ki notranje ime razreši v javni naslov, ali ne razreši ničesar, medtem ko je pot videti popolna.
Dva selektorja, en poskus povezave
Ko se aplikacija poveže z files.corp.example, se pred nastankom paketa zgodita dve iskanji. Razreševalnik odloči, kateri strežnik prejme poizvedbo, z iskalnimi domenami, usmerjevalnimi domenami na povezavo ali izrecnim pravilom profila. Nato usmerjevalna tabela odloči, kam gre dobljeni naslov, z najdaljšim ujemanjem predpone s ciljem.
Nič ne poveže teh dveh odločitev. Zasebna cona lahko odgovori z 10.20.4.11, medtem ko usmerjevalna tabela pošlje 10.20.0.0/16 v tunel, in povezava deluje. Obrnite katero koli in spodleti tako, da je videti kot druga: pravilna politika DNS plus manjkajoča pot da razrešeno ime in časovno omejitev, medtem ko pravilna pot plus javni razreševalnik da naslov, ki se čisto usmeri na napačno mesto.
DNS z razdeljenim obzorjem to zaostri. Isto ime lahko vrne zasebni naslov z notranjega razreševalnika in javni naslov s tistega, obrnjenega proti internetu, zato opomba, ki beleži samo predpono, ne more predvideti, kateri naslov bo odjemalec dejansko uporabil. Zapišite pot razreševalnika, sicer je naslov ugibanje.
Kaj opomba samo o poti izpusti
Zapis samo o poti je neuporaben za najpogostejšo okvaro razdeljenega tunela: imena. Uporabnik poroča, da se intranet ne naloži, tunel je gor in predpona je prisotna. Kdor prevzame zahtevek, nima zapisa, kateri razreševalnik bi moral odgovoriti, nima načina razlikovati napačno iskalno pripono od blokiranega strežnika in nima osnovne črte za primerjavo.
Druga izpustitev je seznam izjem. Zasnova razdeljenega tunela je enako določena s tem, kar ostane zunaj tunela, kot s tem, kar vstopi vanj, izključeni razponi pa se običajno zlomijo prvi, ker lahko bolj specifična lokalna pot ali filter na strani odjemalca preglasi namero, ne da bi se dotaknil profila.
Tretja je oddaljena stran tunela. Pot odjemalca le položi paket na žico; prehod ga mora še vedno posredovati in imeti pot nazaj. strongSwanov vodnik za posredovanje opozarja, da so pravila posredovanja in požarnega zidu na prehodu del funkcije, ne del vodovodarskega dela, ki ga lahko predpostavite.
Polja, ki naredijo opombo izvedljivo
Ena vrstica na tok, tok pa je cilj plus ime plus lastnik. To so polja, ki preživijo stik z resničnim 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 |
Vrstica "kjer živi" je tista, ki jo ljudje preskočijo. Predpona, ki jo potisne strežnik, pot, ki jo doda profil odjemalca, in pot, vtipkana v lupino, se razlikujejo po tem, kdo jih lahko spremeni in ali preživijo ponovno povezavo. Brez tega polja naslednji inženir ne more reči, katero od treh gleda.
En test na pravilo, ne en na tunel
Vsaka vrstica potrebuje dva neškodljiva preverjanja: eno, ki vadi pot, in eno, ki vadi ime. Za pot zahtevajte nekaj, kar mora prečkati tunel, in potrdite pot namesto dosegljivosti, na primer tracert -d 10.20.4.11 v Windows ali ip route get 10.20.4.11 v Linuxu. Za ime poizvedite zasebno ime in zabeležite, kateri strežnik je odgovoril, z uporabo resolvectl query files.corp.example ali dig files.corp.example proti razreševalniku, ki ga opomba navaja.
Dodajte tudi negativno pričakovanje: kaj naj se zgodi, ko je tunel dol. Izključena aplikacija na napravi Android ali iOS z vklopljenim blokiranjem brez VPN morda nima nobene povezljivosti, namizni odjemalec pa lahko pusti isto aplikacijo delovati, medtem ko se tunel znova povezuje. Zapis predvidenega odgovora spremeni "VPN mi je pokvaril aplikacijo" v preverljivo trditev.
Hranite zapis skupaj s konfiguracijo
Shranite opombo ob profilu, ki ga opisuje, in jo verzionirajte s tem profilom. Dokument na wikiju, ki ga nihče ne posodablja, je govorica; tabelo v istem repozitoriju kot potisnjene poti in politika razreševalnika je mogoče pregledati v isti spremembi.
Ko se nekaj zlomi, primerjajte uporabljeno pot in dejanski razreševalnik z zapisom, preden dodate še eno izjemo. Dva od treh pogostih vzrokov — staro pravilo imenskega prostora in pomožni proces zunaj politike aplikacije — sta videti natanko kot okvara VPN in sta nevidna, če opomba navaja samo predpone.
Preden opombo razglasite za dokončano, potrdite, da pisno odgovori na to: katera predpona, za katero družino naslovov; kateri zasebni imenski prostor, s katerim razreševalnikom odgovorjen; katera imena namerno ostanejo javna; kje je vsako pravilo konfigurirano in kdo ga ima; ter edini ukaz, ki dokaže pot, in tisti, ki dokaže ime. Če kaj manjka, bo naslednji incident diagnosticiran od začetka.