WireGuard DNS iPhone-on: a domain csak egy keresési utótag

Egy sort ír a feloldó címével és egy vállalati domainnel, abban a hitben, hogy csak az adott domain nevei használják az alagút feloldóját. Az Apple kliensen most minden név oda megy, és a domain rövid nevei is feloldódnak. A sor két külön dolgot tesz, és csak az egyik szól arról, hogy mely lekérdezéseket kezeli az alagút. A másik egy gépelési kényelem, amelyet a vágyvezérelt olvasat szabályzattá emelt.

Mivé alakul a DNS sor

A kliens a bejegyzést listaként olvassa, és minden elemet alakja szerint osztályoz. Minden, ami címnek tűnik, DNS-kiszolgálóvá válik; minden, ami domainnek tűnik, keresési utótaggá válik. Mindkettő bekerül az alagút beállításaiba, de különböző mezőkbe. Egy szemléltető sor egy olyan alagúthoz, amely privát feloldót és egy belső domaint hordoz, így néz ki.

DNS = 10.24.8.53, lab.internal.example

A cím adja a feloldót. A domain olyan utótagot ad, amely lehetővé teszi, hogy a kliens rövid nevet írjon, és a rendszer a kérdezés előtt hozzáfűzze a többit. Egyik elem sem mond semmit arról, hogy a feloldót erre a domainre korlátozzuk, és pont ezt várják az emberek, de nem kapják meg. A platformon csak egy mező tudja kifejezni ezt a korlátozást, és nem ez a mező.

Két Apple-mező, két különböző feladat

Az Apple a DNS-beállítás objektumában teszi láthatóvá a különbséget. A keresési domainek listája úgy van dokumentálva, mint az egycímkés hosztnevek minősítésére használt lista: írjon be egy csupasz hosztnevet, és a rendszer sorban hozzáfűzheti az egyes utótagokat. Ez kiegészítési szabály, nem útválasztási szabály. Semmi ebben a listában nem dönti el, melyik kiszolgálót kérdezzük.

Az egyeztetési domainek listája más tulajdonság. Azt dönti el, mely névterek használják ezt a DNS-beállítás-készletet, és egy üres bejegyzés az alapértelmezett domaint jelenti, nem egy konkrét utótagot. csomagalagút-beállítások generátora az Apple kliensen ezt a modellt követi. A feldolgozott keresési utótagokat a keresési listába teszi, és ha vannak kiszolgálók, az egyeztetési listát üres karakterláncra állítja. Az eredmény egy alagút-feloldó, amely mindenre válaszol, amit a rendszer küld neki, plusz egy utótag, amely a rövid neveknél segít.

Tehát a sorban szereplő domain nem névtér-választó. Egy másik hozzáadása nem szűkíti, hogy mely lekérdezéseket használ az alagút, és az eltávolítása sem tágítja azokat. Az egyetlen dolog, ami változik, az az, hogy hány rövid név egészül ki.

Miért éri el minden név mégis az alagút feloldóját

Az üres egyeztetési bejegyzéssel az alagút jelölt feloldó a közönséges nevekhez, nem csak a vállalati domainhez. Teljes alagút konfigurációjában ez általában kevéssé számít, mert minden forgalom úgyis az alagútban van. Osztott alagútban ez sokat számít. A nyilvános neveket most olyan feloldó oldhatja fel, amely csak egy privát zónát tart, és a hiba törött VPN-nek látszik, holott valójában egy feloldó, amely a névtérnek csak egy részére válaszol. Az alagút rendben van, a lekérdezések elmennek, és a válaszok üresen jönnek vissza.

Két javítás érhető el, és ezek különböző döntések. Tegye az alagút feloldóját teljes feloldóvá, amely a jóváhagyott útvonalon továbbítja a nyilvános neveket, vagy hagyja abba a nyilvános nevek odaküldését a kliens konfigurációjának módosításával a domainlista helyett. Az első minden lekérdezést az alagúton tart, és bízik a felsőbb szintben. A második néhány lekérdezést helyben tart, és elfogadja, hogy a privát nevek feloldása leállhat, amíg az alagút áll.

Mire lenne valójában szüksége az osztott DNS-nek

A névtérhez kötött feloldószabályzat olyan klienst igényel, amely lehetővé teszi a kifejezését: egyeztessen domaineket az Apple platformokon, vagy használjon egyenértékű beállítást a használt termékben. Egy konfigurációs mező, amely csak kiszolgálókat és utótagokat fogad el, nem tudja kifejezni, akárhogyan írja is be. Egy profil hordozhatja a szabályzatot, mert felügyelt konfigurációt ír le, nem csatlakozáskori tippet. Megnevezheti a domaint, a kiszolgálókat és azt, hogy mi történjen, ha az a domain elérhetetlen. Ez a különbség egy beállítás és egy szerződés között.

Felügyelt Apple-eszközökön ezt általában olyan konfigurációs profil szállítja, amely a domainspecifikus DNS-beállításokat hordozza. Ez más mechanizmus, mint a WireGuard konfigurációs fájl, és a kettő csak akkor létezhet együtt, ha a kliens tiszteletben tartja a profilt. Ellenőrizze, hogyan nevezi a kliense valójában a mezőt, mielőtt feltételezi, hogy a két termék ugyanúgy viselkedik. A Macen futó wg-quick szkript és az iPhone-on futó WireGuard alkalmazás hasonló sorokat olvas, és különböző rétegeken keresztül telepíti őket.

A telepített beállításokat olvassa, ne a konfigurációt

Macen megvizsgálhatja, mire jutott a rendszer, ami tanulságosabb, mint az írt fájl újraolvasása. A feloldók listája megmutatja, mely kiszolgálók mely domainekhez vannak beállítva, a hatókörözött lekérdezések pedig azt, melyik nyert. A sort elrontó kliens ezt itt mutatja, nem az írt fájlban. iOS-en nincs egyenértékű parancssor, ezért ott a bizonyíték egy eredmény: egy privát név, amely az alagúton keresztül oldódik fel, és egy nyilvános név, amelynek válasza elárulja, melyik feloldó felelt.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Ez a két parancs kiírja az aktuális feloldókonfigurációt és az aktív szolgáltatás DNS-kiszolgálóit. Ha az alagút feloldója domain-korlátozás nélküli alapértelmezett feloldóként jelenik meg, a konfiguráció pontosan azt teszi, amit a kliens kért. Javítsa ezt a mechanizmus megváltoztatásával, ne egy második utótag hozzáadásával és annak reményével, hogy a viselkedés megváltozik.