Privát DNS az Azure-ban VPN-en át: resolver végpont vagy forwarder
Mindkét terv privát zónákat válaszol meg az alagúton. Hasonlítsa össze a felügyelt bejövő végpontot egy forwarder VM-mel, majd ellenőrizze az útvonalat, amelynek mindkét esetben léteznie kell.
Egy helyszíni kiszolgáló privát címen éri el az Azure VM-et, mégsem tudja feloldani annak privát gazdanevét, ami miatt az emberek törött alagutat keresnek. Az alagút rendben van. Ami hiányzik, az egy DNS-határ: a helyszíni oldalon semmi sem tudja, hogy egy adott Azure privát zónára a VNeten belüli resolvernek kell válaszolnia. Két terv zárja be ezt a rést, és abban különböznek, hogy végül mit üzemeltetsz, nem abban, hogy működnek-e a lekérdezések.
Az alagút lekérdezéseket szállít, nem zónatudást
A site-to-site kapcsolat útvonalat ad a csomagoknak a két hálózat között. Nem mondja meg a helyszíni DNS-kiszolgálónak, melyik névtér tartozik az Azure-hoz, vagy melyik cím válaszoljon, ezért a lekérdezés vagy elmegy az internetre és üresen tér vissza, vagy soha nem hagyja el a helyi resolvert.
A javításnak két fele van, amelyek könnyen szétválaszthatók. Az egyik fél egy resolver a VNeten belül, amely fogadja az alagúton érkező lekérdezéseket. A másik egy feltételes forwarder a helyszíni oldalon, amely pontosan egy névteret küld annak a resolvernek. Egyik fél sem működik egyedül.
A leírás hátralévő részében tegyük fel, hogy a zóna cloud.corp.example, és kezelj minden címet szemléltetőnek.
A lehetőség: a felügyelt bejövő végpont
Az Azure DNS Private Resolver egy bejövő végpontot biztosít, amely a VNeten kívülről érkező DNS-lekérdezéseket fogad. Egy dedikált delegált alhálózatban telepíted, összekapcsolod a privát zónát azzal a VNettel, és feljegyzed a szolgáltatás által kiosztott bejövő címet.
A helyszíni DNS-kiszolgálón ezután feltételes forwardert hozol létre a pontos névtérhez afelé a cím felé:
Namespace: cloud.corp.example
Forward to: 10.20.2.4A Microsoft hibrid DNS-eljárása dokumentálja a zónaösszekapcsolást és a forwarder lépést is. A felügyelt út nem hagy javítanivaló DNS-szoftvert, és a végpont címe az erőforrás teljes élettartama alatt stabil marad.
Az ár az, hogy most már van egy resolver erőforrásod, annak alhálózat-delegálása és költsége, ami akkor is valós, ha a lekérdezési mennyiség nagyon kicsi.
B lehetőség: forwarder VM a VNeten belül
A régebbi terv DNS-szoftvert futtat egy közönséges VM-en a VNetben: Windows DNS, BIND vagy dnsmasq, a privát zóna pedig vagy helyben van hosztolva, vagy a 168.63.129.16 címen elérhető Azure resolverhez van továbbítva. A helyszíni feltételes forwarder arra a VM privát címére mutat.
Ez a lehetőség ismerős azoknak a csapatoknak, amelyek már üzemeltetnek DNS-kiszolgálókat, és további logikát is hordozhat, például naplózást vagy split-horizon válaszokat. Örökli a DNS-kiszolgáló minden üzemeltetési kötelezettségét is: javítás, második példány a rendelkezésre álláshoz, megfigyelés és újraépítési útvonal, amikor a VM-et lecserélik és a címe megváltozik.
Egy közönséges VNet-gazda nem DNS-proxy addig, amíg a szolgáltatás nincs telepítve és engedélyezve, hogy azoknak az ügyfeleknek válaszoljon, és éppen ezt a lépést hagyják ki az emberek, amikor VM-et klónoznak.
Melyik illik a működésedhez
Az összehasonlítás nem arról szól, melyik terv gyorsabb. Arról szól, akarsz-e egyáltalán DNS-szoftvert üzemeltetni, és igazolja-e a lekérdezési mennyiség azt a felügyelt erőforrást, amely végpont és lekérdezés szerint számláz.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Bármelyik sor döntsön is, a helyszíni forwarder szabálya ugyanúgy néz ki. Ez az a rész, amelynek mindkét tervben léteznie kell, és ez az a rész, amely leggyakrabban hiányzik, amikor valaki jelenti, hogy a feloldás Azure-n belülről működik, de az irodából nem.
Ellenőrizd az útvonalat sorrendben
Erősítsd meg, hogy a zóna ahhoz a VNethez van kapcsolva, amely a resolvert tartalmazza, és hogy a helyszíni forwarder a névteret nevezi meg, nem egy szülő tartományt. A corp.example-hez tartozó forwarder nem fog egyezni a cloud.corp.example-lel, hacsak maga a resolver nem delegál, és az eltérés tiszta negatív választ ad, amely hiányzó rekordnak látszik.
Ezután ellenőrizd, hogy a lekérdezés eléri a végpontot: a helyszíni forrásnak útvonalra van szüksége a resolver címéhez és visszaútra, és az 53-as portot UDP-ben és TCP-ben is engedélyezni kell ott, ahol a házirend engedi. Az NSG nem tud hiányzó zónarekordot adni, és egy helyes zóna nem tud válaszolni egy olyan lekérdezésre, amely soha nem érkezik meg.
Tartsd a kért FQDN-t a kiválasztott resolver mellett, amikor diagnosztizálsz, és különítsd el az időtúllépést a negatív választól. Az időtúllépés útvonal- vagy házirendprobléma. A negatív válasz azt jelenti, hogy a lekérdezés megérkezett, és a névtér nem egyezett. A munka sorrendje: kapcsold össze a zónát, add hozzá a feltételes forwardert, nyisd meg az 53-as portot mindkét irányban, tesztelj egy nevet helyszínről, és csak ezután nézd meg az alkalmazás saját engedélyezését.