A split-tunnel dokumentációnak DNS-szabály kell minden útvonal mellé
Az útvonal cím alapján dönt, a feloldó név alapján dönt. Dokumentálja mindkét választót folyamatonként, mindegyiket egy teszttel, különben a feljegyzés elbukik, amikor a DNS elmozdul.
Egy split-tunnel feljegyzés, amely azt mondja, hogy "az irodai forgalom a VPN-en keresztül megy", egy döntést dokumentált, és további hármat sugallt. A csomagszinten egy útválasztási tábla a célcímet használva választ interfészt; a névszinten egy feloldó a lekérdezést használva választ kiszolgálót, és a két választás egymástól függetlenül történik. Ezért egy helyesen dokumentált előtag még mindig olyan gépet eredményezhet, amely egy belső nevet nyilvános címre old fel, vagy semmit sem old fel, miközben az útvonal tökéletesnek látszik.
Két választó, egy kapcsolódási kísérlet
Amikor egy alkalmazás csatlakozik a files.corp.example címhez, két keresés történik, mielőtt csomag létrejönne. A feloldó eldönti, melyik kiszolgáló kapja a lekérdezést, keresési tartományokat, kapcsolatonkénti útválasztási tartományokat vagy explicit profilszabályt használva. Ezután az útválasztási tábla eldönti, hová megy a kapott cím, a leghosszabb előtag-egyezést használva a céllal.
Semmi sem köti össze ezt a két döntést. Egy privát zóna erre válaszolhat: 10.20.4.11 címmel, miközben az útválasztási tábla a 10.20.0.0/16 tartományt a tunnelbe küldi, és a kapcsolat működik. Fordítsa meg bármelyiket, és úgy hibázik, ahogy a másik látszana: helyes DNS-szabály plusz hiányzó útvonal feloldott nevet és időtúllépést ad, míg helyes útvonal plusz nyilvános feloldó olyan címet ad, amely tisztán a rossz helyre irányul.
A split-horizon DNS élesebbé teszi ezt. Ugyanaz a név privát címet adhat a belső feloldótól és nyilvános címet az internet felé nézőtől, ezért egy csak az előtagot rögzítő feljegyzés nem tudja megjósolni, melyik címet fogja az ügyfél ténylegesen használni. Írja le a feloldó útvonalát, különben a cím találgatás.
Mit hagy ki a csak útvonalról szóló feljegyzés
A csak útvonalról szóló bejegyzés használhatatlan a split-tunnel leggyakoribb hibájához: a nevekhez. A felhasználó jelenti, hogy az intranet nem töltődik be, a tunnel fent van, és az előtag jelen van. Aki átveszi a jegyet, annak nincs bejegyzése arról, melyik feloldónak kellett volna válaszolnia, nincs módja megkülönböztetni a rossz keresési utótagot a blokkolt kiszolgálótól, és nincs összehasonlítási alapja.
A második kihagyás a kivétellista. A split-tunnel kialakítást ugyanannyira meghatározza az, ami a tunnelen kívül marad, mint az, ami belép oda, és a kizárt tartományok általában azok, amelyek először eltörnek, mert egy konkrétabb helyi útvonal vagy egy ügyféloldali szűrő felülírhatja a szándékot a profil érintése nélkül.
A harmadik a tunnel túlsó oldala. Az ügyfél útvonala csak a vezetékre teszi a csomagot; az átjárónak továbbra is továbbítania kell, és visszaúttal kell rendelkeznie. A strongSwan továbbítási útmutatója emlékeztet arra, hogy az átjárón a továbbítási és tűzfal-szabályok a funkció részét képezik, nem a vízvezeték-szerelés részét, amit feltételezhet.
A mezők, amelyek végrehajthatóvá teszik a feljegyzést
Egy sor folyamatonként, és a folyamat egy cél plusz egy név plusz egy tulajdonos. Ezek azok a mezők, amelyek túlélik a valódi incidenssel való találkozást:
| 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 |
A "hol él" sor az, amelyet az emberek kihagynak. A kiszolgáló által tolt előtag, az ügyfélprofil által hozzáadott útvonal és a shellbe gépelt útvonal abban különbözik, hogy ki változtathatja meg őket, és hogy túlélik-e az újracsatlakozást. E mező nélkül a következő mérnök nem tudja megmondani, melyiküket nézi.
Egy teszt szabályonként, nem egy tunnelenként
Minden sornak két ártalmatlan ellenőrzésre van szüksége: egyre, amely az útvonalat gyakorolja, és egyre, amely a nevet. Az útvonalhoz kérjen valamit, aminek át kell haladnia a tunnelen, és az elérhetőség helyett az útvonalat erősítse meg, például tracert -d 10.20.4.11 Windowson vagy ip route get 10.20.4.11 Linuxon. A névhez kérdezze le a privát nevet, és jegyezze fel, melyik kiszolgáló válaszolt, a feljegyzésben megnevezett feloldóval szemben resolvectl query files.corp.example vagy dig files.corp.example használatával.
Adjon hozzá negatív elvárást is: mi történjen, amikor a tunnel le van állva. Egy kizárt alkalmazásnak egy Android vagy iOS eszközön, ahol a VPN nélküli blokkolás be van kapcsolva, egyáltalán nem lehet kapcsolata, és egy asztali ügyfél hagyhatja ugyanazt az alkalmazást működni, miközben a tunnel újracsatlakozik. A szándékolt válasz rögzítése a "a VPN tönkretette az alkalmazásomat" kijelentést ellenőrizhető állítássá teszi.
Tartsa a bejegyzést a konfiguráció mellett
Tárolja a feljegyzést a leírt profil mellett, és verziózza azzal a profillal. Egy wikiben lévő dokumentum, amelyet senki sem frissít, pletyka; egy táblázat ugyanabban a tárolóban, mint a tolt útvonalak és a feloldó házirendje, ugyanabban a változtatásban áttekinthető.
Amikor valami eltörik, hasonlítsa össze az alkalmazott útvonalat és a tényleges feloldót a bejegyzéssel, mielőtt újabb kivételt ad hozzá. A három gyakori ok közül kettő — egy régi névtér-szabály és az alkalmazásházirenden kívüli segédfolyamat — pontosan VPN-hibának látszik, és láthatatlan, ha a feljegyzés csak előtagokat sorol fel.
Mielőtt késznek nevezné a feljegyzést, erősítse meg, hogy írásban válaszol ezekre: melyik előtag, melyik címcsalád számára; melyik privát névtér, melyik feloldó válaszol rá; mely nevek maradnak szándékosan nyilvánosak; hol konfigurálják az egyes szabályokat, és ki birtokolja őket; és az az egy parancs, amely bizonyítja az útvonalat, és az, amely bizonyítja a nevet. Ha bármelyik hiányzik, a következő incidenst nulláról kell diagnosztizálni.