Wêrom in privee-einpunt noch altyd mei in iepenbier adres antwurdet

De laptop makket ferbining, de tunnel meldt dat er oan is, en it opslachaccount wegeret noch altyd elk fersyk. It privee-einpunt bestiet, de rûte nei syn subnet bestiet, en de namme antwurdet óf mei in iepenbier adres óf lost net op. Der is neat mis mei de tunnel: de klant is nea ferteld hokker server foar dy namme antwurde moat. Folgje de oanfraach nei bûten en de kleau wurdt dúdlik.

Begjin by de resolver fan ’e klant

Freegje de klant hokker server er oanfreget wylst de tunnel oan is. In punt-nei-lokaasje-profyl leveret dat adres, en in profyl dat neat leveret lit it bestjoeringssysteem weromfalle op ’e standertynstellingen fan ’e adapter.

Iepenbiere resolvers hawwe gjin sicht op in privee-sône, dat se antwurdzje fan it ynternet, wat krekt harren wurk is. De earste kontrôle is dus it resolveradres dat brûkt wurdt, net de tunnel en net it einpunt.

Lês wat it antwurd eins is

Los de tsjinstnamme op en lês it adres dat weromkomt. In iepenbier antwurd betsjut dat de oanfraach in server berikt hat dy’t de sône net sjen kin. Gjin antwurd betsjut dat de namme allinnich privee bestiet en neat dat de klant berikke kin, hâldt it.

Dy twa útkomsten jouwe ferlykbere applikaasjeflaters en hearre by ferskillende eigners. Ien is in resolver-karprobleem, it oare is in ûntbrekkende sône-keppeling.

In hosts-yngong bewiist it paad, en dan ljocht er

It einpuntadres yn it lokale hosts-bestân sette is de fluchste manier om te bewizen dat de tunnel en de tsjinst-firewall al wurkje. As it fersyk mei dy yngong slagget, is allinnich de nammebepaling stikken. It is ek in wiziging per masine dy’t krekt ien namme dekt.

It helpt it twadde account, it twadde einpunt of in kollega net, en it brekt sûnder warskôging as it einpunt op in nij adres opnij makke wurdt.

Earmer, it lit jo masine oars hâlde en dwaan as dy fan elkenien, en sa oerlibbet in resolver-flater in wike ûndersyk. Brûk it om it paad te befêstigjen, helje it der dan út en reparearje de oarsaak.

Keppelje de sône en diel in resolver út

Twa betingsten moatte tagelyk jilde. De privee-sône moat oan it firtuele netwurk keppele wêze dêr’t it einpunt wennet, en de klant moat syn oanfragen nei in server stjoere dy’t dy sône lêze kin. In ynkommend einpunt fan DNS Private Resolver leveret sa’n adres binnen it netwurk en antwurdet op oanfragen dy’t oer de tunnel komme. Set dat adres yn it VPN-profyl en foegje it privee-efterheaksel ta dat de klant tapasse moat.

In al oanwêzige lokale resolver kin itselde resultaat berikke fia in betingst trochstjoerder rjochte op ’e sône.

Netwurkregels op ’e resolver telle likefolle as routing. As de ynkommende regel it VPN-klantberik útslút, ferrinne oanfragen ynstee fan in ferkeard antwurd te jaan. It is dat ferrinnen dat minsken weromstjoert nei in rûtetabel wêryn’t neat mis is.

Kontrolearje namme, poarte en identiteit yn folchoarder

Wurkje yn folchoarder: los de namme op, befêstigje dat it antwurd privee is, iepenje de poarte, doch dan in autentisearre fersyk. Eltse stap hat syn eigen eigner en syn eigen flatersignatuer.

In privee antwurd folge troch ferrinnen wiist op in rûte of in firewall. In iepenbier antwurd wiist op ’e resolver. In foltôge ferbining dy’t in identiteitsflater weromjout, heart by de tsjinst.

Noch ien flater heart op dizze list. In tsjinst-firewall dy’t in klantadres talit, hâldt op te passen as de pool dat adres nei in werferbining oan in oare sesje jout. Lês it oanropperadres dat de tsjinst fêstlein hat, net dat wat de klant tinkt dat er hat. De twa binne it faker net iens as minsken ferwachtsje. De Azure DNS Private Resolver-riglynen dekke de sône-keppeling en de trochstjoerregeling.