Pritunl se privaat DNS misluk? Voeg ’n noue resolver-roete by

Privaat name los op vir almal op die korporatiewe netwerk en tyd uit vir almal op die VPN. Die resolver antwoord die gateway, die roete daarheen bestaan, en die navraag kry steeds nooit ’n antwoord nie. Wat ontbreek, is nie nog ’n publieke resolver of ’n breër roete nie: dit is ’n bronadres wat die privaat DNS-bediener bereid is om te antwoord.

Bevestig dat die resolver jou kliëntpoel weier

Begin deur te bewys dat die fout oor die bron gaan, nie oor bereikbaarheid nie. Bevraag die privaat resolver direk vanaf ’n gekoppelde kliënt en kyk of die versoek tyd uit of as ’n weiering terugkom. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 wat tyd uit terwyl dieselfde navraag vanaf die gateway slaag, dui op ’n toegangsbeleid op die resolver. ’n SERVFAIL-antwoord dui op iets heeltemal anders, gewoonlik die sone of die opstroom-aanstuurder.

Noteer die kliënt se adres voordat jy toets. ip -4 addr show tun0 op die kliënt, of die huur wat in die konsole gewys word, vertel jou watter poel die resolver sien.

Bevestig dan of die pad hoegenaamd bestaan. ’n Roete wat die resolver-adres in die tonnel stuur, is ’n voorvereiste, nie die oplossing nie; as pakkette nooit aankom nie, word die bronbeleid nooit geraadpleeg nie. Kontroleer dit met ip route get 10.40.0.53 op die kliënt.

Voeg een gasheerroete by in plaas daarvan om alles te vertaal

Pritunl se leiding oor privaat DNS beskryf die noue oplossing: ’n NAT-geaktiveerde /32-roete vir die resolver-adres, met daardie adres gekies as die kliënte se DNS-bediener. Die roete verander die bron wat die resolver sien, net vir DNS-verkeer. Toepassingsverkeer behou die bronbehoudende ontwerp wat jy daarvoor gekies het.

Konfigureer dit deur die bediener se ondersteunde roete-eienaar, nadat jy bestaande roetes vir oorvleueling nagegaan het. In die voorbeeld hierbo is die bestemming 10.40.0.53/32 met NAT geaktiveer, en die kliëntpoel bly 10.90.0.0/24. Moenie die hele privaat reeks vertaal om een diens reg te maak nie, want elke stroomaf-beleid wat op die kliënt se werklike adres staatmaak, sal eerder die gateway begin sien. Bevestig die adres wat die resolver werklik ontvang deur sy navraaglog tydens ’n toetsopsoeking te dophou. ’n Gasheerroete alleen bewys niks oor vertaling of toestemming nie.

Die resolver moet steeds die vertaalde bron op UDP en TCP toelaat, en sy antwoorde moet kan terugkeer. Om die bron te verander kan nie ’n ontbrekende sone of rekord skep nie.

Besluit of die bediener of die kliënt die navraag stuur

Pritunl dokumenteer ook ’n DNS-proxy-reëling gekoppel aan VPN Client DNS Mapping, waar die bediener opstroom-navrae namens kliënte aanstuur. In daardie model behoort die opstroom-bron aan die bediener se eie netwerkkonteks, en ’n kliëntkant-uitsondering is die verkeerde oplossing.

Identifiseer watter model aktief is voordat jy iets byvoeg. Drie oorvleuelende herstellings, ’n proxy, ’n kliënt-resolver-oorheersing en ’n handmatige NAT-skrip, beteken gewoonlik dat niemand vasgestel het: watter komponent die navraag veronderstel is om te stuur. Kyk ook na bootstrap: ’n slegs-privaat resolver kan nie die enigste manier wees om die eindpunt te vind voordat die tonnel bestaan nie, en ’n permanente resolver-wysiging behoort nie die verbinding te oorleef nie.

Toets ’n privaat opsoeking, nie ’n publieke webblad nie

Nadat jy die verandering toegepas en weer gekoppel het, inspekteer die kliënt se effektiewe resolver-konfigurasie, en los dan ’n naam op waarvan jy weet dit bestaan net in die privaat sone. dig intranet.example.net sonder ’n eksplisiete bediener wys wat die kliënt werklik gebruik. Volg dit met ’n versoek na die adres wat daardie opsoeking teruggegee het, want oplossing en dienstoegang is aparte stappe. ’n Blaaier wat publieke werwe deur DNS-over-HTTPS laai, bewys niks oor die bedryfstelsel se privaat resolver-pad nie. ’n Publieke sekondêre resolver is ook nie ’n gesag vir ’n interne sone nie.

Teken die resolver-adres, die /32-roete en die kliënt se DNS-instelling saam in die bediener se notas aan. Die helfte van daardie konfigurasie wat alleen herstel word, reproduseer die oorspronklike fout.

Bevestig laastens dat die tonnel steeds die toepassingsbestemming routeer nadat DNS slaag. Roete, dienstoegang en verifikasie bly onafhanklik van naamoplossing, en ’n werkende opsoeking sê niks oor deurset nie. As die privaat bladsy stadig is maar oplos, het die resolver sy werk gedoen en het die probleem na die pad verskuif.