Pritunl syn privee DNS mislearret? Foegje in smelle resolver-rûte ta
In privee resolver dy’t de VPN-pool negearret hat in útsûndering foar de boarne nedich, net in bredere rûte. Foegje in NAT-aktivearre /32 ta en test in echte privee syktocht.
Privee nammen wurde oplost foar elkenien op it bedriuwsnetwurk en ferrinne foar elkenien op it VPN. De resolver antwurdet de gateway, de rûte dêrhinne bestiet, en de fraach kriget dochs nea in antwurd. Wat ûntbrekt is net in oare publike resolver of in bredere rûte: it is in boarneadres dêr’t de privee DNS-tsjinner ree is om op te antwurdzjen.
Befestigje dat de resolver jo kliïntpool wegeret
Begjin mei te bewizen dat de flater oer de boarne giet, net oer berikberens. Freegje fan in ferbûne kliïnt de privee resolver direkt en sjoch oft it fersyk ferrint of as in wegering weromkomt. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 dat ferrint wylst deselde fraach fan de gateway slagget, wiist op in tagongsbelied op de resolver. In SERVFAIL-antwurd wiist op in hiel oar plak, meastentiids de sône of de opstream-trochstjoerder.
Notearje it adres fan de kliïnt foar it testen. ip -4 addr show tun0 op de kliïnt, of de lease dy’t yn de console sjoen wurdt, fertelt jo hokker pool de resolver sjocht.
Befestigje dan oft it paad wol bestiet. In rûte dy’t it resolver-adres yn de tunnel stjoert is in betingst, net de oplossing; as pakketten nea oankomme, wurdt it boarnebelied nea rieplachte. Kontrolearje it mei ip route get 10.40.0.53 op de kliïnt.
Foegje ien hostrûte ta ynstee fan alles te fertalen
Pritunl syn lieding oer privee DNS beskriuwt de smelle oplossing: in NAT-aktivearre /32-rûte foar it resolver-adres, mei dat adres keazen as de DNS-tsjinner fan de kliïnten. De rûte feroaret de boarne dy’t de resolver sjocht, allinnich foar DNS-ferkear. Tapassingsferkear hâldt it boarnebehâldende ûntwerp dat jo dêrfoar keazen hawwe.
Konfigurearje it fia de stipe rûte-eigner fan de tsjinner, nei’t jo besteande rûtes op oerlaap kontrolearre hawwe. Yn it foarbyld hjirboppe is de bestemming 10.40.0.53/32 mei NAT aktivearre, en de kliïntpool bliuwt 10.90.0.0/24. Fertel net it hiele privee berik om ien tsjinst te reparearjen, want elk streamôf-belied dat op it echte adres fan de kliïnt fertrout, sil ynstee de gateway begjinne te sjen. Befestigje it adres dat de resolver eins ûntfangt troch syn fraachlog te besjen by in testopspoaring. In hostrûte allinnich bewiist neat oer fertaling of tastimming.
De resolver moat it fertaalde boarne noch altyd tastean op UDP en TCP, en syn antwurden moatte werom kinne. It feroarjen fan de boarne kin gjin ûntbrekkende sône of record meitsje.
Beslis oft de tsjinner of de kliïnt de fraach stjoert
Pritunl dokumintearret ek in DNS-proxy-regeling keppele oan VPN Client DNS Mapping, wêrby’t de tsjinner opstream-fragen foar kliïnten trochstjoert. Yn dat model heart it opstream-boarne ta de eigen netwurk-kontekst fan de tsjinner, en in útsûndering oan kliïntekant is de ferkearde oplossing.
Identifisearje hokker model aktyf is foardat jo wat tafoegje. Trije oerlaapjende reparaasjes, in proxy, in kliïnt-resolver-oerskriuwing en in hânmjittich NAT-skript betsjutte meastentiids dat nimmen fêststeld hat: hokker komponint de fraach stjoere moat. Kontrolearje ek bootstrap: in allinnich-privee resolver kin net de ienige manier wêze om it einpunt te finen foardat de tunnel bestiet, en in permaninte resolver-wiziging moat de ferbining net oerlibje.
Test in privee syktocht, net in publike webside
Nei’t jo de wiziging tapast en wer ferbûn hawwe, besjoch de effektive resolver-konfiguraasje fan de kliïnt, en los dan in namme op dêr’t jo fan witte dat dy allinnich yn de privee sône bestiet. dig intranet.example.net sûnder in eksplisite tsjinner lit sjen wat de kliïnt eins brûkt. Folgje it mei in fersyk nei it adres dat dy syktocht weromjoech, want oplossing en tsjinsttagong binne aparte stappen. In browser dy’t publike siden fia DNS-over-HTTPS laadt, bewiist neat oer it privee resolver-paad fan it bestjoeringssysteem. In publike sekundêre resolver is ek gjin autoriteit foar in ynterne sône.
Skriuw it resolver-adres, de /32-rûte en de DNS-ynstelling fan de kliïnt byinoar yn de notysjes fan de tsjinner. De helte fan dy konfiguraasje allinnich wersteld, reprodusearret de oarspronklike flater.
Befestigje úteinlik dat de tunnel de tapassingsbestemming noch altyd rûtet nei’t DNS slagge is. Rûte, tsjinsttagong en autentikaasje bliuwe ûnôfhinklik fan namme-oplossing, en in wurkjende syktocht seit neat oer trochfier. As de privee side stadich is mar oplost, hat de resolver syn wurk dien en is it probleem nei it paad ferhuze.