WireGuard DNS na iPhone: doména je len vyhľadávacia prípona

Napíšete jeden riadok s adresou resolvera a firemnou doménou a očakávate, že len názvy v tejto doméne budú používať resolver tunela. Na klientovi Apple tam teraz idú všetky názvy a krátke názvy v doméne sa tiež prekladajú. Riadok robí dve oddelené veci a len jedna z nich je o tom, ktoré požiadavky tunel spracúva. Tá druhá je pohodlie pri písaní, ktoré bolo zbožným čítaním povýšené na politiku.

Na čo sa riadok DNS rozkladá

Klient číta záznam ako zoznam a každú položku triedi podľa tvaru. Čokoľvek vyzerá ako adresa, sa stane serverom DNS; čokoľvek vyzerá ako doména, sa stane vyhľadávacou príponou. Obe skončia v nastaveniach tunela, ale v rôznych poliach. Ilustratívny riadok pre tunel, ktorý nesie súkromný resolver a jednu internú doménu, vyzerá takto.

DNS = 10.24.8.53, lab.internal.example

Adresa poskytuje resolver. Doména poskytuje príponu, ktorá klientovi umožní napísať krátky názov a systému doplniť zvyšok pred otázkou. Ani jedna položka nehovorí nič o obmedzení resolvera na túto doménu, a to je práve tá časť, ktorú ľudia očakávajú a nedostanú. Toto obmedzenie vie vyjadriť len jedno pole na platforme, a nie je to toto pole.

Dve polia Apple, dve rôzne úlohy

Apple vystavuje toto rozlíšenie vo svojom objekte nastavení DNS. Zoznam vyhľadávacích domén je dokumentovaný ako zoznam používaný na kvalifikáciu jednoznačkových názvov hostiteľov: napíšte holý názov hostiteľa a systém môže postupne pridať každú príponu. To je pravidlo dopĺňania, nie pravidlo smerovania. Nič v tomto zozname nerozhoduje, ktorý server sa pýta.

Zoznam zodpovedajúcich domén je iná vlastnosť. Rozhoduje, ktoré menné priestory používajú túto sadu nastavení DNS, a prázdny záznam znamená predvolenú doménu, nie jednu konkrétnu príponu. generátor nastavení paketového tunela v klientovi Apple sa riadi týmto modelom. Analyzované vyhľadávacie prípony vkladá do zoznamu vyhľadávania a keď sú k dispozícii servery, nastaví zoznam zodpovedajúcich domén na prázdny reťazec. Výsledkom je resolver tunela, ktorý odpovedá na všetko, čo mu systém pošle, plus prípona, ktorá pomáha s krátkymi názvami.

Doména na tomto riadku teda nie je voličom menného priestoru. Pridanie ďalšej nezúži požiadavky, ktoré tunel používa, a odobratie ich tiež nerozšíri. Jediné, čo sa mení, je počet doplnených krátkych názvov.

Prečo sa každý názov stále dostane k resolveru tunela

S prázdnym záznamom zodpovedajúcej domény je tunel kandidátskym resolverom pre bežné názvy, nielen pre firemnú doménu. V konfigurácii plného tunela to zvyčajne veľa neznamená, pretože všetka prevádzka je aj tak v tuneli. V rozdelenom tuneli to znamená veľa. Verejné názvy teraz môže prekladať resolver, ktorý drží len súkromnú zónu, a zlyhanie vyzerá ako pokazený VPN, hoci v skutočnosti ide o resolver, ktorý odpovedá len na časť menného priestoru. Tunel je v poriadku, požiadavky odchádzajú a odpovede sa vracajú prázdne.

K dispozícii sú dve opravy a sú to rôzne rozhodnutia. Urobte z resolvera tunela úplný resolver, ktorý preposiela verejné názvy schválenou cestou, alebo prestaňte posielať verejné názvy tam, a to zmenou konfigurácie klienta, nie zoznamu domén. Prvá drží každú požiadavku v tuneli a dôveruje nadradenému. Druhá drží niektoré požiadavky lokálne a prijíma, že súkromné názvy sa môžu prestať prekladať, kým je tunel vypnutý.

Čo by rozdelený DNS vlastne potreboval

Politika resolvera obmedzená na menný priestor vyžaduje klienta, ktorý vám ju umožní vyjadriť: porovnávajte domény na platformách Apple, alebo ekvivalentné nastavenie v produkte, ktorý používate. Konfiguračné pole, ktoré prijíma len servery a prípony, to vyjadriť nemôže, nech je punktuované akokoľvek. Profil môže politiku niesť, pretože opisuje spravovanú konfiguráciu a nie nápovedu v čase pripojenia. Môže pomenovať doménu, servery a to, čo sa má stať, keď je táto doména nedostupná. To je rozdiel medzi nastavením a zmluvou.

Na spravovaných zariadeniach Apple sa to zvyčajne dodáva prostredníctvom konfiguračného profilu, ktorý nesie nastavenia DNS špecifické pre doménu. Je to iný mechanizmus ako konfiguračný súbor WireGuard a oba môžu existovať spolu len vtedy, keď klient profil rešpektuje. Skôr než predpokladáte, že sa oba produkty správajú rovnako, skontrolujte, ako váš klient pole skutočne nazýva. Skript wg-quick na Macu a aplikácia WireGuard na iPhone čítajú podobné riadky a inštalujú ich cez rôzne vrstvy.

Čítajte nainštalované nastavenia, nie konfiguráciu

Na Macu môžete skontrolovať, kam systém dospel, čo je poučnejšie než znovu čítať súbor, ktorý ste napísali. Zoznam resolverov ukazuje, ktoré servery sú nakonfigurované pre ktoré domény, a obmedzené požiadavky ukazujú, ktorý vyhral. Klient, ktorý riadok pokazí, to ukáže tu, a nie v súbore, ktorý ste napísali. Na iOS neexistuje ekvivalentný príkazový riadok, takže dôkazom je tam výsledok: súkromný názov, ktorý sa prekladá cez tunel, a verejný názov, ktorého odpoveď prezradí, ktorý resolver odpovedal.

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

Tieto dva príkazy vypíšu aktuálnu konfiguráciu resolvera a servery DNS aktívnej služby. Ak sa resolver tunela zobrazuje ako predvolený resolver bez obmedzenia domény, konfigurácia robí presne to, o čo klient požiadal. Opravte to zmenou mechanizmu, nie pridaním druhej prípony a nádejou, že sa správanie zmení.