WireGuard DNS na iPhonu: doména je jen vyhledávací přípona

Napíšete jeden řádek s adresou resolveru a firemní doménou a čekáte, že jen jména v této doméně budou používat resolver tunelu. Na klientu Apple tam teď jdou všechna jména a krátká jména v doméně se také překládají. Řádek dělá dvě oddělené věci a jen jedna z nich je o tom, které dotazy tunel zpracovává. Ta druhá je pohodlí při psaní, které bylo zbožným čtením povýšeno na politiku.

Na co se řádek DNS rozděluje

Klient čte záznam jako seznam a každou položku třídí podle tvaru. Cokoli vypadá jako adresa, se stane serverem DNS; cokoli vypadá jako doména, se stane vyhledávací příponou. Obě skončí v nastavení tunelu, ale v různých polích. Ilustrativní řádek pro tunel, který nese soukromý resolver a jednu interní doménu, vypadá takto.

DNS = 10.24.8.53, lab.internal.example

Adresa poskytuje resolver. Doména poskytuje příponu, která klientovi umožní napsat krátké jméno a systému doplnit zbytek před dotazem. Ani jedna položka neříká nic o omezení resolveru na tuto doménu, a to je přesně ta část, kterou lidé očekávají a nedostanou. Toto omezení umí vyjádřit jen jedno pole na platformě, a není to toto pole.

Dvě pole Apple, dva různé úkoly

Apple toto rozlišení vystavuje ve svém objektu nastavení DNS. Seznam vyhledávacích domén je dokumentován jako seznam používaný ke kvalifikaci jednoznačkových názvů hostitelů: napište holý název hostitele a systém může postupně přidat každou příponu. To je pravidlo doplňování, ne pravidlo směrování. Nic v tomto seznamu nerozhoduje, který server se ptá.

Seznam odpovídajících domén je jiná vlastnost. Rozhoduje, které jmenné prostory používají tuto sadu nastavení DNS, a prázdný záznam znamená výchozí doménu, nikoli jednu konkrétní příponu. generátor nastavení paketového tunelu v klientu Apple se řídí tímto modelem. Analyzované vyhledávací přípony vkládá do seznamu vyhledávání a když jsou k dispozici servery, nastaví seznam odpovídajících domén na prázdný řetězec. Výsledkem je resolver tunelu, který odpovídá na vše, co mu systém pošle, plus přípona, která pomáhá s krátkými jmény.

Doména na tomto řádku tedy není voličem jmenného prostoru. Přidání další nezúží dotazy, které tunel používá, a odebrání je také nerozšíří. Jediné, co se mění, je počet doplněných krátkých jmen.

Proč se každé jméno stále dostane k resolveru tunelu

S prázdným záznamem odpovídající domény je tunel kandidátským resolverem pro běžná jména, nejen pro firemní doménu. V konfiguraci plného tunelu to obvykle moc neznamená, protože veškerý provoz je stejně v tunelu. V rozděleném tunelu to znamená hodně. Veřejná jména teď může překládat resolver, který drží jen soukromou zónu, a selhání vypadá jako rozbitý VPN, když je to vlastně resolver, který odpovídá jen na část jmenného prostoru. Tunel je v pořádku, dotazy odcházejí a odpovědi se vracejí prázdné.

K dispozici jsou dvě opravy a jsou to různá rozhodnutí. Udělejte z resolveru tunelu úplný resolver, který předává veřejná jména schválenou cestou, nebo přestaňte posílat veřejná jména tam, a to změnou konfigurace klienta, ne seznamu domén. První drží každý dotaz v tunelu a důvěřuje nadřazenému. Druhá drží některé dotazy lokálně a přijímá, že soukromá jména se mohou přestat překládat, dokud je tunel vypnutý.

Co by rozdělený DNS vlastně potřeboval

Politika resolveru omezená na jmenný prostor vyžaduje klienta, který vám ji umožní vyjádřit: porovnávejte domény na platformách Apple, nebo ekvivalentní nastavení v produktu, který používáte. Konfigurační pole, které přijímá jen servery a přípony, to vyjádřit nemůže, ať je punktuované jakkoli. Profil může politiku nést, protože popisuje spravovanou konfiguraci, a ne nápovědu v čase připojení. Může pojmenovat doménu, servery a to, co se má stát, když je tato doména nedostupná. To je rozdíl mezi nastavením a smlouvou.

Na spravovaných zařízeních Apple se to obvykle dodává prostřednictvím konfiguračního profilu, který nese nastavení DNS specifická pro doménu. Je to jiný mechanismus než konfigurační soubor WireGuard a oba mohou existovat společně jen tehdy, když klient profil respektuje. Než předpokládáte, že se oba produkty chovají stejně, zkontrolujte, jak váš klient pole skutečně nazývá. Skript wg-quick na Macu a aplikace WireGuard na iPhonu čtou podobné řádky a instalují je přes různé vrstvy.

Čtěte nainstalovaná nastavení, ne konfiguraci

Na Macu můžete prohlédnout, k čemu systém dospěl, což je užitečnější než znovu číst soubor, který jste napsali. Seznam resolverů ukazuje, které servery jsou nakonfigurovány pro které domény, a omezené dotazy ukazují, který vyhrál. Klient, který řádek zkomolí, to ukáže tady, ne v souboru, který jste napsali. Na iOS není ekvivalentní příkazový řádek, takže důkazem je tam výsledek: soukromé jméno, které se překládá přes tunel, a veřejné jméno, jehož odpověď prozradí, který resolver odpověděl.

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

Tyto dva příkazy vypíšou aktuální konfiguraci resolveru a servery DNS pro aktivní službu. Pokud se resolver tunelu objevuje jako výchozí resolver bez omezení domény, konfigurace dělá přesně to, o co klient požádal. Opravte to změnou mechanismu, ne přidáním druhé přípony a nadějí, že se chování změní.