WireGuard DNS iPhone’is: domeen on ainult otsingujärelliide

Kirjutate ühe rea resolveri aadressi ja ettevõtte domeeniga, oodates, et ainult selle domeeni nimed kasutavad tunneliresolverit. Apple’i kliendis lähevad nüüd kõik nimed sinna ja ka domeeni lühikesed nimed lahendatakse. Rida teeb kahte eraldi asja ja ainult üks neist puudutab seda, milliseid päringuid tunnel käsitleb. Teine on trükkimise mugavus, mille soovmõtlemine poliitikaks ülendas.

Milleks DNS-rida parsitakse

Klient loeb kirje loendina ja liigitab iga elemendi kuju järgi. Kõik, mis näeb välja nagu aadress, saab DNS-serveriks; kõik, mis näeb välja nagu domeen, saab otsingujärelliiteks. Mõlemad jõuavad tunneli seadetesse, aga erinevatesse väljadesse. Illustreeriv rida tunnelile, mis kannab privaatset resolverit ja ühte sisemist domeeni, näeb välja nii.

DNS = 10.24.8.53, lab.internal.example

Aadress annab resolveri. Domeen annab järelliite, mis lubab kliendil kirjutada lühikese nime ja süsteemil enne küsimist ülejäänu lisada. Kumbki element ei ütle midagi resolveri selle domeeniga piiramise kohta ja just seda inimesed ootavad, aga ei saa. Platvormil saab seda piirangut väljendada ainult üks väli ja see ei ole see väli.

Kaks Apple’i välja, kaks erinevat tööd

Apple toob selle erinevuse esile oma DNS-seadete objektis. Otsingudomeenide loend on dokumenteeritud loendina, mida kasutatakse ühe sildiga hostinimede kvalifitseerimiseks: tippige paljas hostinimi ja süsteem võib iga järelliite kordamööda lisada. See on lõpetamise reegel, mitte marsruutimise reegel. Miski selles loendis ei otsusta, millist serverit küsitakse.

Sobivusdomeenide loend on teine omadus. See otsustab, millised nimeruumid kasutavad seda DNS-seadete kogumit, ja tühi kirje tähendab vaikedomeeni, mitte ühte kindlat järelliidet. pakett-tunneli seadete generaator Apple’i kliendis järgib seda mudelit. See paneb parsitud otsingujärelliited otsinguloendisse ja kui serverid on olemas, seab sobivusloendi tühjaks stringiks. Tulemuseks on tunneliresolver, mis vastab kõigele, mida süsteem sellele saadab, pluss järelliide, mis aitab lühikeste nimedega.

Seega ei ole domeen sellel real nimeruumi valija. Teise lisamine ei kitsenda, milliseid päringuid tunnel kasutab, ja selle eemaldamine ei laienda neid samuti. Ainus, mis muutub, on see, kui palju lühikesi nimesid lõpetatakse.

Miks iga nimi jõuab ikka tunneliresolverini

Tühja sobivuskirjega on tunnel tavanimede jaoks kandidaatresolver, mitte ainult ettevõtte domeeni jaoks. Täistunneli konfiguratsioonis on sellel tavaliselt vähe tähtsust, sest kogu liiklus on niikuinii tunnelis. Jagatud tunnelis on sellel suur tähtsus. Avalikke nimesid võib nüüd lahendada resolver, mis hoiab ainult privaatset tsooni, ja tõrge näeb välja nagu katkine VPN, kuigi tegelikult on see resolver, mis vastab ainult osale nimeruumist. Tunnel on korras, päringud lahkuvad ja vastused tulevad tühjadena tagasi.

Saadaval on kaks parandust ja need on erinevad otsused. Tehke tunneliresolverist täielik resolver, mis edastab avalikud nimed kinnitatud teed pidi, või lõpetage avalike nimede sinna saatmine, muutes kliendi konfiguratsiooni, mitte domeenide loendit. Esimene hoiab iga päringu tunnelis ja usaldab ülemvoolu. Teine hoiab osa päringuid kohalikult ja aktsepteerib, et privaatsed nimed võivad lakkata lahendamast, kui tunnel on maas.

Mida jagatud DNS tegelikult vajaks

Nimeruumiga piiratud resolveripoliitika nõuab klienti, mis lubab teil seda väljendada: sobitage domeene Apple’i platvormidel või kasutage samaväärset seadet tootes, mida kasutate. Konfiguratsiooniväli, mis võtab vastu ainult servereid ja järelliiteid, ei saa seda väljendada, ükskõik kuidas seda punktueeritakse. Profiil saab poliitikat kanda, sest see kirjeldab hallatavat konfiguratsiooni, mitte vihjet ühendamise ajal. See saab nimetada domeeni, serverid ja selle, mis peaks juhtuma, kui see domeen ei ole kättesaadav. See on vahe seade ja lepingu vahel.

Hallatud Apple’i seadmetes antakse seda tavaliselt konfiguratsiooniprofiili kaudu, mis kannab domeenipõhiseid DNS-seadeid. See on teine mehhanism kui WireGuardi konfiguratsioonifail ja need kaks saavad koos eksisteerida ainult siis, kui klient profiili austab. Kontrollige, kuidas teie klient välja tegelikult nimetab, enne kui eeldate, et kaks toodet käituvad ühtemoodi. Macil olev wg-quick skript ja iPhone’is olev WireGardi rakendus loevad sarnaseid ridu ja paigaldavad need eri kihtide kaudu.

Lugege paigaldatud seadeid, mitte konfiguratsiooni

Macil saate uurida, milleni süsteem jõudis, mis on informatiivsem kui kirjutatud faili uuesti lugemine. Resolverite loend näitab, millised serverid on milliste domeenide jaoks konfigureeritud, ja piiratud päringud näitavad, milline võitis. Klient, mis rea rikub, näitab seda siin, mitte failis, mille kirjutasite. iOS-is pole samaväärset käsurida, seega on tõendiks seal tulemus: privaatne nimi, mis lahendatakse tunneli kaudu, ja avalik nimi, mille vastus paljastab, milline resolver vastas.

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

Need kaks käsku trükivad praeguse resolveri konfiguratsiooni ja aktiivse teenuse DNS-serverid. Kui tunneliresolver ilmub vaike-resolverina ilma domeenipiiranguta, teeb konfiguratsioon täpselt seda, mida klient palus. Parandage see mehhanismi muutmisega, mitte teise järelliite lisamisega ja lootusega, et käitumine muutub.