Azure од тачке до локације се повезује, али ниједан приватни ресурс не одговара

Повезано је стање тунела, а не тврдња о доступности. Клијент од тачке до локације може да заврши IKE, добије адресу и ипак нигде не стигне, јер портал прослеђује саобраћај само за мреже које VNet већ зна. Изведите ових пет провера по реду и зауставите се на првом неуспеху. Прескакање напред је начин на који се DNS проблем сат времена третира као проблем заштитног зида.

Редослед је важнији од списка.

Провера 1: одлучите шта тунел треба да носи

Azure VPN Gateway завршава тунел и прослеђује саобраћај који припада VNet-у; онније општи интернет излаз. Ако корисници очекују да њихово прегледање изађе преко Azure, дизајн је погрешан пре него што уопште уђе било какво подешавање клијента. Укључите split tunneling да локални интернет остане на локалном путу, и користите NAT инстанцу или тунел од локације до локације када је заиста потребна фиксна излазна адреса.

Запишите до чега клијент треба да стигне пре него што било шта тестирате. Без тог списка, сваки делимичан резултат изгледа као напредак.

Провера 2: упоредите адресне просторе пре сертификата

Преклапање се процењује на ширим опсезима, па се две мреже које на нивоу подмреже изгледају различито ипак сударају ако им се родитељски блокови преклапају. Подмрежа портала мора да буде посвећена и довољно велика за SKU, а базен адреса клијента не сме да се судари са VNet-ом или са било чим доступним преко peering-а. Промените план и поново распоредите, јер додавање рута као компензација ствара тунел који ради за нека одредишта, а необјашњиво не за друга. Обезбеђивање овде гласно пада, што је добар случај.

Аутентикација је следећа капија. Профили са сертификатом, RADIUS и Entra ID нису заменљиви, и клијентски пакет се разликује за сваки.

Провера 3: разрешите приватно име изнутра

Клијент задржава свој resolver осим ако преузети профил не носи DNS сервере VNet-а, а тај списак се уграђује при преузимању. Додајте forwarder унутар VNet-а, поставите га као DNS сервер VNet-а, затим поново преузмите и увезите клијентски пакет. Поновна употреба старог пакета тестира само стари списак resolver-а.

Прво тестирајте адресу, јер то одваја рутирање од именовања у једном кораку: Test-NetConnection 10.20.1.4 -Port 3389.

Ако адреса одговара, а име не, питајте resolver директно са Resolve-DnsName files.corp.example -Server 10.20.0.4. Ако обоје не успе, дефект није у DNS-у и треба да престанете да мењате DNS поставке. DNS платформе Azure на 168.63.129.16 одговара само изнутра из VNet-а, па клијент споља не може да користи ту адресу као resolver.

Провера 4: тестирајте услугу иза тунела

Здрав тунел и затворен порт изгледају исто са стране клијента. Проверите заштитни зид госта, затим мрежну безбедносну групу на подмрежи или NIC-у, затим да ли услуга слуша на приватној адреси, а не само на loopback-у. Дозволите базен клијената као извор уместо да отварате правило ка интернету, и запамтите да SMB ка Azure Files захтева да пут приватне крајње тачке иде кроз тунел. Када ресурс одговара по IP-у, али не по имену, вратите се на проверу 3 уместо да дирате портал.

Једна табела држи слојеве одвојене док радите:

Провера 5: забележите профил пре ескалације

У тикет ставите тип портала, тип тунела, метод аутентикације и оперативни систем клијента. Профил IKEv2 са сертификатом и профил RADIUS падају из различитих разлога, а клијент направљен за други тип тунела повезује се само када портал понуди компатибилан протокол.

За мали тим, издржљив дизајн је један VNet, један DNS forwarder и документован split-tunnel клијент. Ако је захтев фиксни јавни излаз, завршите тунел од локације до локације на заштитном зиду који контролишете и усмерите интернет саобраћај тамо, уместо да од портала од тачке до локације тражите нешто за шта никада није направљен.