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 tunneling. Ако изискването е фиксиран публичен изход, прекратете тунел сайт към сайт на защитна стена, която контролирате, и насочете интернет трафика там, вместо да искате от шлюза точка към сайт да прави нещо, за което никога не е бил създаден.