Azure P2S VPN nevar atrisināt privāta galapunkta nosaukumu

Jūs pievienojat point-to-site tuneli, pingojat privāto adresi, atverat lietotni un tā vietā saņemat 403 vai sertifikāta kļūdu. Abi simptomi norāda uz DNS, taču tie ir dažādi bojājumi: viens nozīmē, ka klients atrisināja publisko adresi, otrs – ka tas atrisināja privāto adresi un pēc tam piedāvāja nosaukumu, ko sertifikāts nesedz. Veiciet zemāk esošās pārbaudes pēc kārtas un apstājieties pie pirmās kļūmes, jo hosts ieraksts vai kešatmiņā saglabāta atbilde var likt katrai nākamajai pārbaudei iziet nepareiza iemesla dēļ. Es šo kārtību glabāju teksta failā blakus saviem VPN profiliem, jo labojums neko nemaina tunelī un visu maina tajā, ko klients zina.

Sāciet ar adresi, ko klients faktiski saņem

Jautājiet risinātājam tieši, nevis uzticieties lietotnei. Windows nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net parāda, kuru skatu klients saņēma. Publiska atbilde nozīmē, ka nekas tālāk nesasniegs galapunktu; galapunkta privātā adrese nozīmē, ka DNS ir pabeigts un nākamā pārbaude ir pats savienojums.

Privāts galapunkts nepārdēvē pakalpojumu. Konts vai lietotne saglabā savu parasto pilnībā kvalificēto nosaukumu, un galapunkts maina tikai adresi, uz kuru šis nosaukums tiek atrisināts klientiem virtuālajā tīklā. Tāpēc viens un tas pats resursdatora nosaukums tiek atrisināts privāti no VM tīklā un publiski no klēpjdatora, kuram nekad netika dots privātais skats.

Pārbaudiet zonu, tās saiti un ierakstu pirms tuneļa

Jāizpildās trim nosacījumiem vienlaikus: privātā zona pastāv, tā ir saistīta ar virtuālo tīklu, kurā VPN vārteja un klienti ieiet Azure, un tajā ir A ieraksts galapunktam, kas norāda uz privāto adresi. Saistiet zonu ar nesaistītu tīklu, un vārteja turpinās atrisināt publisko ierakstu, kamēr tunelī viss izskatīsies vesels.

Zonu nosaukumi pieder pakalpojumiem, nevis privātiem savienojumiem kopumā. App Service parasti izmanto privatelink.azurewebsites.net, krātuvei un SQL ir savas nosaukumu telpas, un citas pakalpojuma zonas aizņemšanās rada zonu, kas pastāv un neatbild neko noderīgu.

Dodiet klientam risinātāju, ko tas patiešām sasniedz

168.63.129.16 atbild no Azure virtuālajām mašīnām un nav DNS serveris klēpjdatoram point-to-site tuneļa otrā pusē. Klientam vajag caur tuneli sasniedzamu risinātāju: Azure DNS Private Resolver ienākošo galapunktu, pāradresētāju virtuālajā tīklā vai DNS servera ierakstus, kas pārnesti VPN klienta profilā, lai klients jautātu virtuālajam tīklam tieši.

Konfigurēts, bet nesasniedzams risinātājs uzvedas tieši tāpat kā nekāds risinātājs, un simptoms ir taimauts, nevis nepareiza atbilde, tāpēc to nepareizi nolasa kā ugunsmūra problēmu. Pārbaudiet to ar vaicājumu, kas tunelim jāpārnes, nevis ar publisku nosaukumu, kas caur vietējo saiti tik un tā būtu izdevies.

Ja pāradresējat, nevis stumjat iestatījumus, pāradresējiet nosaukumu telpu, kas pieder privātajai zonai, privatelink.azurewebsites.net, nevis visu azurewebsites.net. Nosacīts pāradresētājs, kas norij visu vecākdomēna sufiksu, sūta uz Azure katru pakalpojuma meklējumu, tostarp tos, kuriem jāpaliek lokāliem.

Izmantojiet nosaukumu, kuram sertifikāts tika izsniegts

Kad adrese ir pareiza, parādās otrais bojājums. Krātuve un App Service publicē privatelink aizstājvārdu, un šis aizstājvārds ne vienmēr ir sertifikātā esošais nosaukums. AzCopy augšupielāde uz privatelink.blob.core.windows.net neizturēja validāciju; tā pati augšupielāde uz <account>.blob.core.windows.net/<container> tika atrisināta uz privāto adresi un izturēja, tāpēc tā palika privātajā ceļā bez apiešanas.

Noteikums ir spēkā pārlūkā un arī App Service: pievienojieties ar resursdatora nosaukumu, ko sertifikāts sedz, un ļaujiet DNS nodrošināt privāto adresi. Neizmantojiet validācijas apiešanu, jo tā nosaukuma kļūdu pārvērš drošības regresijā. Veiksmīgs ping pierāda maršrutu un neko nepasaka par nosaukumu rokas sasveicināšanā, tāpēc šīs paliek atsevišķas pārbaudes.

Četru soļu kārtība, kas izolē katru slāni

1. Apstipriniet, ka VPN klientam ir adrese no point-to-site kopas un maršruts uz galapunkta privāto adresi.
2. Atrisiniet tieši to nosaukumu, ko izmanto lietotne, un salīdziniet atbildi ar galapunkta adresi.
3. Atveriet TCP savienojumu ar galapunktu pakalpojuma portā, pēc tam nolasiet šajā savienojumā uzrādīto sertifikāta nosaukumu.
4. Autorizāciju pārbaudiet tikai tagad, jo strādājošs ceļš un derīgs sertifikāts vēl nedod piekļuvi resursam.

Noraidīts savienojums, kamēr adrese ir pareiza, norāda uz tīkla drošības grupu vai privātā galapunkta savienojuma stāvokli, nevis DNS, tāpēc pārbaudiet tos pirms risinātāja iestatījumu atkārtotas rediģēšanas. TLS nosaukuma neatbilstība aizsūta jūs atpakaļ uz URL resursdatora nosaukumu un sertifikāta subject. Turiet kopā atrisināšanas izvadi, sertifikāta nosaukumu un precīzu URL; šīs trīs vērtības izskaidro lielāko daļu šo gadījumu, neaiztiekot vārteju.

Izmantojiet VM virtuālajā tīklā kā kontroli. Ja nosaukums tur tiek atrisināts privāti, bet no tuneļa publiski, zona un ieraksts ir pareizi, un vienīgā atšķirība ir klienta risinātāja ceļš, ko apstiprināt ir ātrāk nekā vēl viena galapunkta konfigurācijas pārskatīšana.

Klienti arī kešo. Ieraksts, kas publiski atbildēja pirms desmit minūtēm, atbild arī pēc zonas labošanas, tāpēc pirms atkārtotas pārbaudes notīriet kešatmiņu. Windows ipconfig /flushdns notīra klienta kešatmiņu; nosaukumu atrisināšanas politikas noteikumi paliek, nosaka, kurš sufikss uz kuru serveri iet, un var turpināt sūtīt nosaukumu telpu uz risinātāju, kuru tikko aizstājāt.

Kur pieder hosts ieraksts

Galapunkta adreses pievienošana hosts failam ir laba diagnostika un slikts dizains. Tas pierāda, ka nosaukuma un adreses atbilstība ir trūkstošā daļa, un ļauj pārbaudīt visu pēc šī soļa, taču tas ir neredzams jūsu lietotājiem, salūzt, kad mainās galapunkta adrese, un paslēpj zonu, kurai būtu jāatbild.

Palicis testa ieraksts ir sliktāks par novecojušu kešatmiņu, jo atkarībā no kļūdas virziena tas var likt salabotajam ceļam izskatīties salūzušam vai salūzušajam ceļam izskatīties salabotam. Noņemiet to pirms pēdējās palaišanas un atrisiniet tikai ar ražošanas risinātāju.

Īsiem nosaukumiem vajag meklēšanas sufiksu, bet pilnībā kvalificētiem nevajag, tāpēc vispirms pārbaudiet pilnībā kvalificēto nosaukumu un pēc tam izlemiet, vai darbplūsmai vajag sufiksu, kas tiek stumts caur klienta profilu. Microsoft dokumentē zonu nosaukumus un ierakstu formas katram pakalpojumam savās DNS norādēs privātiem galapunktiem; lasiet sava pakalpojuma ierakstu, nevis kopējiet zonu no cita.