Split-tunneli dokumentatsioon vajab DNS-reeglit iga marsruudi kõrvale
Marsruut otsustab aadressi järgi, resolver otsustab nime järgi. Dokumenteerige mõlemad valijad iga voo kohta, kumbki ühe testiga, muidu nurjub märkus, kui DNS nihkub.
Split-tunneli märkus, mis ütleb "kontoriliiklus läheb VPN-i kaudu", on dokumenteerinud ühe otsuse ja vihjanud kolmele teisele. Paketikihis valib marsruutimistabel liidese sihtaadressi järgi; nimekihis valib resolver serveri päringu järgi ning need kaks valikut tehakse sõltumatult. Seetõttu võib õigesti dokumenteeritud prefiks ikkagi anda masina, mis lahendab sisemise nime avalikuks aadressiks, või ei lahenda üldse midagi, samal ajal kui marsruut näeb täiuslik välja.
Kaks valijat, üks ühenduskatse
Kui rakendus ühendub aadressiga files.corp.example, toimub kaks otsingut enne, kui pakett tekib. Resolver otsustab, milline server päringu saab, kasutades otsingudomeene, lingipõhiseid marsruutimisdomeene või profiili selgesõnalist reeglit. Seejärel otsustab marsruutimistabel, kuhu saadud aadress läheb, kasutades pikimat prefiksivastet sihtkohaga.
Miski ei ühenda neid kahte otsust. Privaatne tsoon võib vastata aadressiga 10.20.4.11, samal ajal kui marsruutimistabel saadab 10.20.0.0/16 tunnelisse, ja ühendus töötab. Pöörake kumbki ümber ja see nurjub viisil, mis näeb välja nagu teine: õige DNS-poliitika pluss puuduv marsruut annab lahendatud nime ja ajalõpu, samas kui õige marsruut pluss avalik resolver annab aadressi, mis marsruutub puhtalt valesse kohta.
Split-horizon DNS muudab selle teravamaks. Sama nimi võib tagastada privaatse aadressi sisemisest resolverist ja avaliku aadressi internetile suunatud resolverist, nii et märkus, mis registreerib ainult prefiksi, ei suuda ennustada, millist aadressi klient tegelikult kasutab. Kirjutage resolveri tee üles, muidu on aadress oletus.
Mida ainult marsruudi märkus välja jätab
Ainult marsruudi kirje on kasutu kõige tavalisema split-tunneli tõrke jaoks: nimed. Kasutaja teatab, et sisevõrk ei laadi, tunnel on üleval ja prefiks on olemas. Kes pileti üle võtab, ei tea, milline resolver oleks pidanud vastama, ei oska eristada valet otsingusufiksit blokeeritud serverist ega oma võrdlusalust.
Teine väljajätt on erandite loend. Split-tunneli disaini määrab sama palju see, mis jääb tunnelist välja, kui see, mis sinna sisse läheb, ja välistatud vahemikud on tavaliselt need, mis esimesena katkevad, sest spetsiifilisem kohalik marsruut või kliendipoolne filter võib kavatsuse üle kirjutada ilma profiili puutumata.
Kolmas on tunneli kaugem pool. Kliendi marsruut paneb paketi ainult juhtmele; lüüs peab selle ikkagi edasi suunama ja omama tagasiteed. strongSwani edasisaatmise juhend tuletab meelde, et edasisaatmise ja tulemüüri reeglid lüüsil on funktsiooni osa, mitte torutöö, mida võib eeldada.
Väljad, mis teevad märkuse täidetavaks
Üks rida voo kohta, ja voog on sihtkoht pluss nimi pluss omanik. Need on väljad, mis peavad vastu tõelise juhtumiga kokkupuutel:
| 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 |
Rida "kus see elab" on see, mille inimesed vahele jätavad. Serveri lükatud prefiks, kliendiprofiili lisatud marsruut ja shelli trükitud marsruut erinevad selle poolest, kes saab neid muuta ja kas need peavad ühenduse taastamisele vastu. Ilma selle väljata ei saa järgmine insener öelda, millist kolmest ta vaatab.
Üks test reegli kohta, mitte üks tunneli kohta
Iga rida vajab kahte kahjutut kontrolli: üks harjutab marsruuti ja teine harjutab nime. Marsruudi jaoks taotlege midagi, mis peab tunnelist läbi minema, ja kinnitage tee, mitte kättesaadavus, näiteks tracert -d 10.20.4.11 Windowsis või ip route get 10.20.4.11 Linuxis. Nime jaoks pärige privaatset nime ja registreerige, milline server vastas, kasutades resolvectl query files.corp.example või dig files.corp.example märkuses nimetatud resolveri vastu.
Lisage ka negatiivne ootus: mis peaks juhtuma, kui tunnel on maas. Välistatud rakendusel Androidi või iOS-i seadmes, kus on sisse lülitatud blokeerimine ilma VPN-ita, ei pruugi olla üldse ühendust, ja töölauaklient võib jätta sama rakenduse tööle, samal ajal kui tunnel taastub. Kavatsetud vastuse registreerimine muudab "VPN rikkus mu rakenduse" kontrollitavaks väiteks.
Hoidke kirje koos konfiguratsiooniga
Hoidke märkust selle profiili kõrval, mida see kirjeldab, ja versioneerige seda koos selle profiiliga. Wiki dokument, mida keegi ei uuenda, on kuulujutt; tabel samas hoidlas lükatud marsruutide ja resolveri poliitikaga on ühe muudatusega üle vaadatav.
Kui midagi katkeb, võrrelge rakendatud marsruuti ja kehtivat resolverit kirjega enne, kui lisate veel ühe erandi. Kolmest tavalisest põhjusest kaks — vana nimeruumi reegel ja rakenduse poliitikast väljaspool olev abiprotsess — näevad täpselt välja nagu VPN-i tõrge ja on nähtamatud, kui märkus loetleb ainult prefikse.
Enne kui kuulutate märkuse valmis, kinnitage, et see vastab kirjalikult järgmisele: milline prefiks, millise aadressiperekonna jaoks; milline privaatne nimeruum, millise resolveri poolt vastatud; millised nimed jäävad teadlikult avalikuks; kus iga reegel on konfigureeritud ja kes selle omanik on; ning üks käsk, mis tõestab marsruuti, ja üks, mis tõestab nime. Kui midagi sellest puudub, diagnoositakse järgmine juhtum nullist.