WireGuard DNS iPhonean: domeinua bilaketa-atxikiz bat besterik ez da

Ebaztaile baten helbidea eta enpresa-domeinu bat dituen lerro bat idazten duzu, domeinu horretako izenek soilik tunelaren ebaztailea erabiliko dutelakoan. Apple bezeroan, izen guztiak bertara joaten dira orain, eta domeinuko izen laburrak ere ebazten dira. Lerroak bi gauza bereizi egiten ditu, eta horietako bat soilik da tunelak zein kontsulta kudeatzen dituenari buruzkoa. Bestea idazteko erraztasuna da, irakurketa oparo batek politika bihurtu duena.

Zertan banatzen da DNS lerroa

Bezeroak sarrera zerrenda gisa irakurtzen du eta elementu bakoitza itxuraren arabera sailkatzen du. Helbide itxura duen guztia DNS zerbitzari bihurtzen da; domeinu itxura duen guztia bilaketa-atxikiz bihurtzen da. Biak tunelaren ezarpenetan amaitzen dira, baina eremu desberdinetan. Ebaztaile pribatu bat eta barne-domeinu bat daraman tunelerako lerro ilustratibo bat horrela ikusten da.

DNS = 10.24.8.53, lab.internal.example

Helbideak ebaztailea ematen du. Domeinuak atxikiz bat ematen du, bezeroari izen labur bat idazteko eta sistemari gainerakoa eransten uzteko, galdetu aurretik. Bi elementuetako batek ere ez du ezer esaten ebaztailea domeinu horretara mugatzeaz, eta hori da jendeak espero duen eta lortzen ez duen zatia. Plataforman eremu batek soilik adierazi dezake murrizketa hori, eta ez da hau.

Apple-ren bi eremu, bi lan desberdin

Apple-k bere DNS ezarpenen objektuan erakusten du bereizketa. Bilaketa-domeinuen zerrenda etiketa bakarreko ostalari-izenak kalifikatzeko erabiltzen den zerrenda gisa dokumentatuta dago: idatzi ostalari-izen soil bat eta sistemak atxikiz bakoitza txandaka erants diezaioke. Osatzeko araua da, ez bideratze-araua. Zerrenda horretan ezerk ez du erabakitzen zein zerbitzari galdetzen den.

Bat etortzeko domeinuen zerrenda beste propietate bat da. DNS ezarpen multzo hau zein izen-espaziok erabiltzen duten erabakitzen du, eta sarrera hutsak domeinu lehenetsia esan nahi du, ez atxikiz zehatz bat. pakete-tunelaren ezarpenen sortzailea Apple bezeroan eredu horri jarraitzen dio. Analizatutako bilaketa-atxikizak bilaketa-zerrendan jartzen ditu, eta zerbitzariak daudenean, bat etortze zerrenda kate hutsera ezartzen du. Emaitza sistemak bidaltzen dion guztiari erantzuten dion tunel ebaztailea da, gehi izen laburretan laguntzen duen atxikiz bat.

Beraz, lerro horretako domeinu bat ez da izen-espazioaren hautatzaile bat. Beste bat gehitzeak ez du murrizten tunelak zein kontsulta erabiltzen dituen, eta kentzeak ez ditu zabaltzen ere. Aldatzen den gauza bakarra zenbat izen labur osatzen diren da.

Zergatik iristen den izen bakoitza tunelaren ebaztaileari oraindik

Bat etortze sarrera hutsarekin, tunela izen arrunten ebaztaile hautagaia da, ez enpresaren domeinura soilik. Tunel osoko konfigurazioan honek normalean gutxi axola du, trafiko guztia tunelaren barruan dago eta. Tunel bananduan asko axola du. Izen publikoak orain zona pribatua soilik duen ebaztaile batek ebatz ditzake, eta hutsegiteak VPN apurtu bat dirudi, izen-espazioaren zati bat soilik erantzuten duen ebaztaile bat denean. Tunela ondo dago, kontsultak irten egiten dira, eta erantzunak hutsik itzultzen dira.

Bi konponketa daude eskuragarri eta erabaki desberdinak dira. Egin tunelaren ebaztailea izen publikoak bide onartutik birbidaltzen dituen ebaztaile oso bat, edo utzi izen publikoak hara bidaltzeari bezeroaren konfigurazioa aldatuz, domeinuen zerrenda ordez. Lehenengoak kontsulta bakoitza tunelan mantentzen du eta goiko fluxuan fidatzen da. Bigarrenak kontsulta batzuk tokian mantentzen ditu eta onartzen du izen pribatuek ebazteari utz diezaioketela tunela behera dagoen bitartean.

Zer behar lukeen DNS bananduak benetan

Izen-espaziora mugatutako ebaztaile-politika batek hura adierazteko aukera ematen duen bezero bat behar du: egin domeinuak bat Apple plataformetan, edo baliokidea den ezarpen bat erabiltzen duzun produktuan. Zerbitzariak eta atxikizak soilik onartzen dituen konfigurazio-eremu batek ezin du hura adierazi, nola puntuatu ere. Profil batek politika eraman dezake, kudeatutako konfigurazio bat deskribatzen duelako, ez konektatzeko uneko iradokizun bat. Domeinua, zerbitzariak eta domeinu hori eskuragarri ez dagoenean zer gertatu behar den izenda ditzake. Hori da ezarpen baten eta kontratu baten arteko aldea.

Apple gailu kudeatuetan, normalean domeinuari dagozkion DNS ezarpenak daramatzan konfigurazio-profil baten bidez ematen da. WireGuard konfigurazio-fitxategiaren mekanismo desberdina da, eta biak elkarrekin egon daitezke bezeroak profila errespetatzen badu soilik. Egiaztatu zure bezeroak nola deitzen dion eremuari, bi produktuak berdin jokatzen dutela suposatu aurretik. Mac bateko wg-quick script batek eta iPhone bateko WireGuard aplikazioak antzeko lerroak irakurtzen dituzte eta geruza desberdinen bidez instalatzen dituzte.

Irakurri instalatutako ezarpenak, ez konfigurazioa

Mac batean sistema zerekin amaitu zen ikus dezakezu, idatzi duzun fitxategia berriro irakurtzea baino informatiboagoa dena. Ebaztaileen zerrendak zein zerbitzari dauden zein domeinutarako konfiguratuta erakusten du, eta kontsulta mugatuek zein atera zen irabazle erakusten dute. Lerroa hondatzen duen bezero batek hemen erakusten du, idatzi duzun fitxategian ez. iOS-n ez dago baliokidea den komando-lerrorik, beraz han froga emaitza bat da: tunelaren bidez ebazten den izen pribatu bat eta erantzunak zein ebaztailek erantzun zuen agerian uzten duen izen publiko bat.

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

Bi komando hauek uneko ebaztaile-konfigurazioa eta zerbitzu aktiboaren DNS zerbitzariak inprimatzen dituzte. Tunelaren ebaztailea domeinu-murrizketarik gabeko ebaztaile lehenetsi gisa agertzen bada, konfigurazioak bezeroak eskatu zuen zehazki egiten du. Konpondu hori mekanismoa aldatuz, bigarren atxikiz bat gehituz eta portaera aldatuko den itxaronez ez.