Проверката на IP поток в Azure казва „разрешено“, но VPN пак не работи

Тунелът сайт към сайт е свързан, ВМ е здрава, а локалният клиент не получава нищо. Отваряте Network Watcher, пускате проверка на IP поток и тя казва Access allowed, затова тикетът се затваря като проблем с VPN. Този резултат не означава това, което изглежда, защото проверката на IP поток оценява правилата за сигурност за описания от вас поток и никога не проверява дали Azure има маршрут към вашия локален префикс.

Въпросът за филтрирането и въпросът за маршрутизирането са отделни и Network Watcher отговаря на тях с различни инструменти. Да знаете кой от двата сте задали е по-голямата част от диагностиката.

Какво всъщност решава проверката на IP поток

Проверката на IP поток взема ВМ, мрежов интерфейс, посока, стойности на петорката и протокол, после съобщава решението на правилата на NSG и на администратора по сигурността за този поток. Работи с TCP и UDP, така че не е тестер за ICMP правила и блокиран ping не доказва нищо за услугата ви. Подайте ѝ реалния поток, а не предположение. Входяща връзка от локалната мрежа към порт на база данни е различно описание от изходяща връзка, която ВМ инициира.

Ако шлюзът преобразува адреси, използвайте адреса на източника, който достига границата, която оценявате, а не този от конфигурацията на клиента. Четете резултата и такъв, какъвто е. Access allowed означава, че филтриращият слой би пропуснал пакета, ако пристигне, и нищо повече.

Това, което не може да ви каже, е маршрутът, избран от Azure, дали гостуващата защитна стена разрешава порта и дали нещо слуша. Тези неща живеят на други слоеве.

Какво добавят следващият хоп и ефективните маршрути

Следващият хоп отговаря на въпрос за препращане: за тази дестинация кой тип следващ хоп избира Azure, на кой адрес, от коя таблица с маршрути. Ефективните маршрути изброяват какво реално има NIC. Пуснете и двете и получавате пътя от страна на Azure, който зелената проверка на IP поток оставя празен.

Прегледът на Microsoft „Преглед на проверката на IP поток“ посочва обхвата на филтрирането директно, а страниците за следващ хоп и диагностика на маршрути покриват страната на препращането. Цитирайте правилната страница, когато записвате находката.

Командите са достатъчно кратки, за да се пуснат от шел. az network nic show-effective-route-table изброява маршрутите, приложени към интерфейса. az network watcher show-next-hop с източник и дестинация връща избрания хоп. Сравнете префикса, който ви интересува, с тази таблица и после потвърдете кой запис печели.

Изминете обратния път от NIC на ВМ

Правете това от NIC на целевата ВМ, за префикса на локалния клиент, а не за интернет. Обратният път е мястото, където се крият повредите сайт към сайт, защото проверката на състоянието на тунела само съобщава, че асоциациите за сигурност са вдигнати.

Ако очакваният маршрут липсва, проверете отдалечените префикси, които конфигурацията на шлюза предоставя, дизайна на свързаността на VNet и всяка настройка за разпространение на маршрути. Обектът на локален мрежов шлюз описва локалната страна; съществуването му не доказва, че всеки необходим префикс присъства и е предпочетен на NIC. Това са различни факти и само един от тях се показва в обобщението на портала.

Четете типа на следващия хоп, вместо да копирате пример

Пътят през управляван VPN шлюз обикновено показва VirtualNetworkGateway като тип на следващия хоп. VirtualAppliance описва различен дизайн на препращане, обикновено защитна стена или мрежово виртуално устройство.

Не създавайте маршрут на устройство към предполагаема крайна точка на VPN, само защото стар отговор във форум е използвал този тип. Ако дефиниран от потребителя маршрут отменя предвидения път, намерете собственика и целта му, преди да го промените. Втори NIC също може да промени кой интерфейс използва гостът и премахването му може да счупи друга услуга, вместо да поправи този маршрут.

Преминете към границата, която все още се проваля

Когато филтрирането и маршрутизирането съвпадат с дизайна, повредата е другаде. Проверете собствената таблица с маршрути на госта, защитната му стена и дали слушателят е свързан с очаквания адрес. После проверете защитените селектори за трафик на VPN и локалния път за отговор. Всяка от тези проверки е отделен тест с отделен резултат.

Завършете с разрешена заявка от приложение и наблюдения от двата края. Резултат „разрешено“ и правилен следващ хоп са две части от доказателства, а не доказателство, че връзката е успяла.