Azure P2S VPN kin de namme fan in privee-einpunt net oplosse

Jo ferbine de point-to-site-tunnel, pingje it privee-adres, iepenje de app en krije ynstee in 403 of in sertifikaatflater. Beide symptomen wize nei DNS, mar it binne ferskillende flaters: de iene betsjut dat de klient it iepenbiere adres oplost hat, de oare dat er it privee-adres oplost hat en doe in namme oanbea dy't it sertifikaat net dekt. Wurkgje de kontrôles hjirûnder yn folchoarder ôf en stop by de earste flater, want in hosts-ynfier of in bewarre antwurd kin elke lettere kontrôle om de ferkearde reden slagje litte. Ik hâld dizze folchoarder yn in tekstbestân njonken myn VPN-profylen, want de oplossing feroaret neat oan de tunnel en alles oan wat de klient wit.

Begjin mei it adres dat de klient echt krijt

Freegje de resolver direkt ynstee fan de applikaasje te fertrouwen. Op Windows lit nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net sjen hokker werjefte de klient krige. In iepenbier antwurd betsjut dat neat fierder it einpunt berikke sil; it privee-adres fan it einpunt betsjut dat DNS dien is en dat de folgjende kontrôle de ferbining sels is.

In privee-einpunt ferneamt de tsjinst net. It akkount of de app hâldt syn gewoane folslein kwalifisearre namme, en it einpunt feroaret allinnich it adres dêr't dy namme foar klanten binnen it firtuele netwurk nei oplost. Dêrom wurdt deselde hostnamme privee oplost fan in VM yn it netwurk en iepenbier fan in laptop dy't nea de privee werjefte krige.

Kontrolearje de sône, har keppeling en it record foar de tunnel

Trije betingsten moatte tagelyk jilde: de privee sône bestiet, se is keppele oan it firtuele netwurk dêr't de VPN-gateway en de klanten Azure yn komme, en se befettet in A-record foar it einpunt dat nei it privee-adres wiist. Keppelje de sône oan in net besibbe netwurk en de gateway bliuwt it iepenbiere record oplosse, wylst alles oan de tunnel noch sûn liket.

Sônenammen hearre by tsjinsten, net by privee keppelings yn 't algemien. App Service brûkt normaal privatelink.azurewebsites.net, opslach en SQL hawwe har eigen nammeromten, en it lienen fan in sône fan in oare tsjinst leveret in sône op dy't bestiet en neat nuttich antwurdet.

Jou de klient in resolver dy't er echt berikke kin

168.63.129.16 antwurdet fan Azure-firtuele masines en is gjin DNS-tsjinner foar in laptop oan 'e oare kant fan in point-to-site-tunnel. De klient hat in resolver nedich dy't troch de tunnel berikber is: in yngeand einpunt fan Azure DNS Private Resolver, in trochstjoerder binnen it firtuele netwurk, of DNS-tsjinner-ynfierren dy't yn it VPN-klientprofyl meidroegen wurde, sadat de klient it firtuele netwurk direkt freget.

In konfigurearre mar net berikbere resolver hâldt him krekt as gjin resolver, en it symptoom is in time-out ynstee fan in ferkeard antwurd, dêrom wurdt it ferkeard as in firewallprobleem lêzen. Test it mei in fraach dy't de tunnel drage moat, net mei in iepenbiere namme dy't oer de lokale keppeling dochs wol slagje soe.

As jo trochstjoere ynstee fan ynstellings te triuwen, stjoer dan it nammeromte troch dat de privee sône besit, privatelink.azurewebsites.net ynstee fan hiel azurewebsites.net. In betingst trochstjoerder dy't it hiele âlderlike suffiks opslokt, stjoert elke syktocht foar de tsjinst nei Azure, ek dy't lokaal bliuwe moatte.

Brûk de namme dêr't it sertifikaat foar útjûn is

Sadree't it adres goed is, komt de twadde flater boppe. Opslach en App Service publisearje in privatelink-alias, en dy alias is net needsaaklik de namme yn it sertifikaat. In AzCopy-upload nei privatelink.blob.core.windows.net slagge net foar de falidaasje; deselde upload nei <account>.blob.core.windows.net/<container> waard nei it privee-adres oplost en slagge, dus bleau er op it privee paad sûnder oerskriuwing.

De regel jildt yn in browser en ek foar App Service: ferbine mei de hostnamme dy't it sertifikaat dekt en lit DNS it privee-adres leverje. Gryp net nei it omsielen fan falidaasje, want dat makket fan in nammeflater in feiligensregresje. In slagge ping bewiist de rûte en seit neat oer de namme yn 'e hânskud, dêrom bliuwe dit aparte kontrôles.

In folchoarder fan fjouwer stappen dy't elke laach isolearret

1. Befêstigje dat de VPN-klient in adres út 'e point-to-site-pool hat en in rûte nei it privee-adres fan it einpunt.
2. Los de krekte namme op dy't de applikaasje brûkt en fergelykje it antwurd mei it adres fan it einpunt.
3. Iepenje in TCP-ferbining nei it einpunt op 'e tsjinstpoarte en lês dan de sertifikaatnamme dy't op dy ferbining oanbean wurdt.
4. Testje no pas de autorisaasje, want in wurkjend paad en in jildich sertifikaat jouwe noch gjin tagong ta de boarne.

In wegere ferbining wylst it adres goed is, wiist nei de netwurkfeiligensgroep of de ferbiningstatus fan it privee-einpunt, net nei DNS, dus kontrolearje dy foar't jo de resolver-ynstellings wer bewurkje. In TLS-nammeferskil stjoert jo werom nei de hostnamme yn 'e URL en it subject fan it sertifikaat. Hâld de oplossingsútfier, de sertifikaatnamme en de krekte URL byinoar; dy trije wearden ferklearje de measte fan dizze gefallen sûnder de gateway oan te reitsjen.

Brûk in VM binnen it firtuele netwurk as kontrôle. As de namme dêr privee oplost en fan 'e tunnel iepenbier, binne de sône en it record goed en is it iennige ferskil it resolverpaad fan 'e klient, wat flugger te befêstigjen is as noch in rûn troch de einpuntkonfiguraasje.

Klanten bewarje ek. In record dy't tsien minuten lyn iepenbier antwurde, antwurdet noch nei't jo de sône reparearre hawwe, dus leegje de bewarring foar't jo wer teste. Op Windows rommet ipconfig /flushdns de klientbewarring op; regels foar namme-oplossingsbelied bliuwe, beslute hokker suffiks nei hokker tsjinner giet en kinne it nammeromte trochstjoere nei de resolver dy't jo krekt ferfongen hawwe.

Wêr't in hosts-ynfier heart

It adres fan it einpunt oan in hosts-bestân taheakje is in goede diagnostyk en in min ûntwerp. It bewiist dat de namme-nei-adres-keppeling it ûntbrekkende stik is en lit jo alles dêrnei testje, mar it is ûnsichtber foar jo brûkers, brekt as it adres fan it einpunt feroaret en ferberget de sône dy't antwurdzje moatte soe.

In efterbleaune testynfier is slimmer as in ferâldere bewarring, want it kin it reparearre paad as brutsen of it brutsen paad as reparearre lykje litte, ôfhinklik fan 'e rjochting fan 'e flater. Ferwiderje it foar de lêste rûn en los allinnich op mei de produksje-resolver.

Koarte nammen hawwe in syksuffiks nedich en folslein kwalifisearre nammen net, dus testje earst de folslein kwalifisearre namme en beslute dan oft de wurkstream in suffiks nedich hat dat troch it klientprofyl triuwd wurdt. Microsoft dokumintearret de sônenammen en recordfoarmen per tsjinst yn syn rjochtlinen foar DNS fan privee-einpunten; lês de ynfier foar jo tsjinst ynstee fan in sône fan in oare te kopiearjen.