DNS net deur jou eie VPN-resolver laat loop: n deurloop

Volg een naamsopsoeking vanaf die oomblik dat jy dit tik. Die blaaier vra die bedryfstelsel, die bedryfstelsel vra die resolver wat sy beleid kies, en die navraag verlaat die toestel oor een of ander koppelvlak met een of ander vervoer. Jou VPN-ontwerp se die antwoord moet van ’n spesifieke resolver oor ’n spesifieke pad kom. Die gaping tussen daardie twee stellings is wat jy opstel en daarna afdwing.

Stap 1: Benoem die resolver en die pad

Skryf drie dinge neer voordat jy aan ’n firewall raak: die resolver-adres, die protokol en poort wat jy verwag, en die koppelvlak waardeur die navraag moet uitgaan. Sonder daardie lys is ’n reel ’n vermoede oor verkeer eerder as die afdwinging van ’n besluit. ’n VPN kan toepassingsdata dra terwyl DNS ’n aparte reeling volg, en dit is op sigself nie ’n fout nie. Dit is wat gebeur wanneer niemand die klient anders vertel het nie.

Om die pad uitdruklik te benoem is die verskil tussen ’n ontwerp en ’n ongeluk. Dit gee jou ook iets om later te toets, want elke waarneming kan met ’n geskrewe verwagting vergelyk word. Hou daardie lys in die veranderingskaartjie eerder as in iemand se kop.

Stap 2: Stel die beleid waar dit werklik woon

Resolver-keuse hoort by die klient: die bedryfstelsel se netwerkinstelling, die VPN-klient se eie instellings of ’n bestuurde blaaierbeleid. Stel dit eerste daar, met die meganisme wat die platform ondersteun, want ’n firewall kan nie ’n klient dwing om ’n resolver te kies waarvan hy nooit gehoor het nie. Op ’n split-tonnel-klient se jy uitdruklik watter domeine na die interne resolver gaan. Op ’n bestuurde vloot is ’n blaaierbeleid dikwels die enigste hefboom vir DoH, want die blaaier kan sy eie geenkripteerde resolver onafhanklik van die stelselinstelling kies.

Slaan dit oor en gaan reguit na die firewall, en jy kry ’n reel wat die regte resolver toelaat plus ’n klient wat dit nooit gebruik nie. Die reel lyk korrek en die resolver-logboeke bly leeg, wat ’n verwarrende paar is om te ontfout. Stel eers die keuse op, dwing dit dan af.

Stap 3: Dwing die pad nou af

Voeg nou die netwerktoestemming by vir die toegelate pad: die resolver-adres, die protokol en poort, en die koppelvlak waardeur dit moet uitgaan. Hou die reel beperk tot daardie resolver in plaas daarvan om alle uitgaande DNS toe te laat. Die drie paadjies hieronder is die wat ’n moderne klient kan volg, en net die eerste word deur ’n poort-53-reel gedek.

Om DoH en DoT te blokkeer is wettig; om te aanvaar dat ’n poort-53-reel hulle reeds geblokkeer het, is nie. ’n Blaaier met DoH los name op via ’n pad wat jou reel nooit beskryf het nie, en ’n toepassing met sy eie resolver doen dieselfde. Skryf elke pad neer wat jy wil toelaat en elkeen wat jy wil weier. ’n Reel wat nie ’n pad noem nie, het nie daaroor besluit nie.

Stap 4: Volg private en publieke name

Split-DNS stuur doelbewus net private naamruimtes na ’n interne resolver terwyl publieke name elders heen gaan, so meer as een resolver in die ontwerp is nie ’n lek nie. Die lek is ’n navraag wat na jou resolver moes gaan en elders aankom, of ’n onbereikbare beoogde pad wat die klient stil laat terugval. Daardie twee gevalle is wat om na te kyk. Volg ’n interne en ’n publieke naam onder die beoogde beleid en let op watter resolver elkeen beantwoord het.

’n Toetswerf wat jou resolver rapporteer is ’n wenk, nie bewys nie, want dit sien net navrae wat hom bereik het. Teken die navraag aan die klientkant op wanneer jy moet weet watter pad dit werklik gevolg het, en vergelyk dan albei waarnemings. Wanneer hulle verskil, het jy ’n terugval gevind wat niemand gedokumenteer het nie.

As die resolver-adres reg is maar onbereikbaar, is die probleem roetering of filtering eerder as beleid. Spoor die navraag na daardie adres en bevestig dat die antwoord op die verwagte koppelvlak terugkom voordat jy enige resolver-instelling verander.

Stap 5: Hou n weg terug oop

Voordat jy gateway-DNS-toegang verskerp, bevestig ’n herstelmetode wat nie van naamsopsoeking afhang nie. ’n Stukkende resolver maak elke herstelgereedskap moeiliker bereikbaar, ook die wat jy sou gebruik om die verandering terug te draai. Hou ’n plaaslike konsole of ’n buiteband-pad oop tot die nuwe beleid bewys is. Verwyder dit eers nadat die beleid ’n herverbinding deurstaan het.

Na ’n herverbinding of ’n blaaierbeleid-opdatering, ondersoek die effektiewe toestand weer, want albei kan die resolver verander sonder om jou reel te verander. Die vereiste is ’n bekende ontvanger en ’n beskermde pad vir die navrae, nie ’n gerusstellende resolver-etiket op een skermkiekie nie. Die RFC 8484 DNS over HTTPS-spesifikasie is die verwysing vir die geenkripteerde pad wat jou poortreel nie sien nie.