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 клиент. Ако барањето е фиксен јавен излез, завршете тунел од локација до локација на огнена брана што ја контролирате и насочете го интернет сообраќајот таму, наместо да барате од портата од точка до локација нешто за што никогаш не била изградена.