Csak a saját VPN-feloldón keresztül engedjük a DNS-t: lépésről lépésre

Kövessünk végig egyetlen névfeloldást attól a pillanattól, amikor beírjuk. A böngésző kérdezi az operációs rendszert, az operációs rendszer azt a feloldót kérdezi, amelyet a házirendje kiválaszt, és a lekérdezés valamilyen interfészen, valamilyen átvitellel hagyja el az eszközt. A VPN-tervünk azt mondja, hogy a válasznak egy meghatározott feloldótól, meghatározott úton kell jönnie. A két állítás közötti rés az, amit beállítunk, majd kikényszerítünk.

1. lépés: nevezzük meg a feloldót és az utat

Írjunk le három dolgot, mielőtt tűzfalhoz nyúlunk: a feloldó címét, az elvárt protokollt és portot, valamint az interfészt, amelyen a lekérdezésnek ki kell mennie. E lista nélkül a szabály találgatás a forgalomról, nem egy döntés végrehajtása. A VPN viheti az alkalmazások adatait, miközben a DNS külön elrendezést követ, és ez önmagában nem hiba. Ez történik akkor, ha senki nem mondott mást a kliensnek.

Az út kimondott megnevezése a különbség a terv és a véletlen között. Ez ad valamit későbbi tesztelésre is, mert minden megfigyelés összevethető egy írásos elvárással. Tartsuk a listát a változásjegyben, ne valakinek a fejében.

2. lépés: a házirendet oda tegyük, ahol valóban él

A feloldó kiválasztása a kliens dolga: az operációs rendszer hálózati beállítása, a VPN-kliens saját beállításai vagy egy kezelt böngészőházirend. Először oda tegyük, a platform által támogatott mechanizmussal, mert a tűzfal nem kényszerítheti a klienst olyan feloldó választására, amelyről soha nem hallott. Osztott alagútú kliensen mondjuk ki, mely tartományok mennek a belső feloldóhoz. Kezelt flottán a böngészőházirend gyakran az egyetlen eszköz a DoH-hoz, mert a böngésző a rendszerbeállítástól függetlenül választhatja a saját titkosított feloldóját.

Ha ezt kihagyjuk és egyenesen a tűzfalhoz megyünk, olyan szabályt kapunk, amely engedi a helyes feloldót, mellé pedig olyan klienst, amely soha nem használja. A szabály helyesnek látszik, a feloldó naplói pedig üresek maradnak, ami zavarba ejtő páros a hibakereséshez. Először a választást állítsuk be, aztán kényszerítsük ki.

3. lépés: szűken kényszerítsük ki az utat

Most adjuk hozzá az engedélyezett út hálózati engedélyét: a feloldó címét, a protokollt és portot, valamint az interfészt, amelyen ki kell mennie. Tartsuk a szabályt erre a feloldóra szűkítve ahelyett, hogy minden kimenő DNS-t engednénk. Az alábbi három utat járhatja egy modern kliens, és csak az elsőt fedi le egy 53-as portra vonatkozó szabály.

A DoH és a DoT blokkolása jogszerű; azt feltételezni, hogy egy 53-as portos szabály már blokkolta őket, nem az. A DoH-t használó böngésző olyan úton oldja fel a neveket, amelyet a szabályunk soha nem írt le, és a saját feloldót hozó alkalmazás ugyanezt teszi. Írjunk le minden utat, amelyet engedélyezni akarunk, és mindegyiket, amelyet el akarunk utasítani. Az a szabály, amely nem nevez meg utat, nem döntött róla.

4. lépés: kövessük a privát és a nyilvános neveket

Az osztott DNS szándékosan csak a privát névtereket küldi belső feloldóhoz, a nyilvános nevek máshová mennek, tehát egynél több feloldó a tervben nem szivárgás. A szivárgás az a lekérdezés, amelynek a feloldónkhoz kellett volna mennie és máshol bukkan fel, vagy egy elérhetetlen tervezett út, amelytől a kliens csendben visszaesik. Ezt a két esetet kell keresni. Kövessünk egy belső és egy nyilvános nevet a tervezett házirend mellett, és jegyezzük fel, melyik feloldó válaszolt melyikre.

Egy tesztoldal, amely a feloldónkat jelenti, nyom, nem bizonyíték, mert csak azokat a lekérdezéseket látja, amelyek elérték. A kliens oldalán rögzítsük a lekérdezést, amikor tudni kell, melyik utat választotta valójában, majd hasonlítsuk össze a két megfigyelést. Ha nem egyeznek, olyan visszaesést találtunk, amelyet senki nem dokumentált.

Ha a feloldó címe helyes, de elérhetetlen, a probléma az útválasztásban vagy a szűrésben van, nem a házirendben. Kövessük a lekérdezést arra a címre, és erősítsük meg, hogy a válasz az elvárt interfészen tér vissza, mielőtt bármilyen feloldóbeállítást módosítunk.

5. lépés: hagyjunk utat visszafelé

Mielőtt szigorítjuk az átjáró DNS-hozzáférését, erősítsünk meg egy helyreállítási módot, amely nem függ a névfeloldástól. A törött feloldó minden javítóeszközt nehezebben elérhetővé tesz, azokat is, amelyekkel a változást visszavonnánk. Tartsunk nyitva egy helyi konzolt vagy egy sávon kívüli utat, amíg az új házirend be nem bizonyosodik. Csak akkor távolítsuk el, ha a házirend túlélt egy újracsatlakozást.

Újracsatlakozás vagy böngészőházirend-frissítés után ismét nézzük meg a tényleges állapotot, mert mindkettő megváltoztathatja a feloldót anélkül, hogy a szabályunk változna. A követelmény ismert címzett és védett út a lekérdezésekhez, nem egy megnyugtató feloldócímke egyetlen képernyőképen. Az RFC 8484 DNS over HTTPS specifikáció a hivatkozás arra a titkosított útra, amelyet a portszabályunk nem lát.