Azure проверката на IP тек вели дозволено, но VPN сепак не успева

Тунелот од локација до локација е поврзан, VM е здрава, но локалниот клиент не добива ништо. Отворате Network Watcher, ја извршувате проверката на IP тек и таа вели Access allowed, па тикетот се затвора како проблем со VPN. Тој резултат не значи тоа што изгледа, бидејќи проверката на IP тек ги оценува безбедносните правила за текот што го опишавте и никогаш не проверува дали Azure има рута до вашиот локален префикс.

Прашањето за филтрирање и прашањето за рутирање се одделни, а Network Watcher одговара на нив со различни алатки. Да знаете кое го поставивте е најголемиот дел од дијагнозата.

Што всушност одлучува проверката на IP тек

Проверката на IP тек зема VM, мрежен интерфејс, насока, вредности на петорката и протокол, а потоа го известува решението на правилото на NSG и на безбедносниот администратор за тој тек. Работи на TCP и UDP, па не е тестер на ICMP правила и блокиран ping не докажува ништо за вашата услуга. Дајте ѝ го вистинскиот тек наместо претпоставка. Влезната врска од локалната средина до порта на база на податоци е различен опис од излезната врска што ја започнува VM.

Ако портата преведува адреси, користете ја изворната адреса што стигнува до границата што ја оценувате, а не таа од конфигурацијата на клиентот. Читајте го резултатот и онаков каков што е. Access allowed значи дека филтерскиот слој би го пропуштил пакетот ако пристигне, и ништо повеќе.

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

Што додаваат следниот скок и ефективните рути

Следниот скок одговара на прашање за препраќање: за оваа дестинација кој тип на следен скок го избира Azure, на која адреса, од која табела на рути. Ефективните рути наведуваат што NIC навистина има. Извршете ги двете и ќе го добиете патот од страната на Azure што зелената проверка на IP тек го остава празен.

Прегледот на проверката на IP тек од Microsoft директно го наведува опсегот на филтрирање, додека страниците за следниот скок и за дијагностика на рути ја покриваат страната на препраќањето. Цитирајте ја вистинската страница кога го запишувате наодот.

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

Поминете го повратниот пат од NIC на VM

Правете го ова од NIC на целната VM, за префиксот на локалниот клиент, не за интернетот. Повратниот пат е местото каде се кријат дефектите од локација до локација, бидејќи проверката на состојбата на тунелот само известува дека безбедносните асоцијации се подигнати.

Ако очекуваната рута недостасува, проверете ги оддалечените префикси што ги дава конфигурацијата на портата, дизајнот на поврзување на VNet и секое поставување за ширење рути. Објектот на локална мрежна порта ја опишува локалната страна; неговото постоење не докажува дека секој потребен префикс е присутен и претпочитан на NIC. Тоа се различни факти, и само еден од нив се појавува во резимето на порталот.

Читајте го типот на следниот скок наместо да копирате пример

Патот низ управувана VPN порта обично прикажува VirtualNetworkGateway како тип на следен скок. VirtualAppliance опишува поинаков дизајн на препраќање, обично firewall или мрежен виртуелен уред.

Не создавајте рута на уред кон претпоставена VPN крајна точка само затоа што стар одговор на форум го користел тој тип. Ако рута дефинирана од корисникот ја надминува предвидената патека, пронајдете го нејзиниот сопственик и цел пред да ја смените. Втора NIC исто така може да смени кој интерфејс го користи гостинот, а нејзиното отстранување може да скрши друга услуга наместо да ја поправи оваа рута.

Преминете на границата што сè уште не успева

Кога филтрирањето и рутирањето и двете одговараат на дизајнот, дефектот е на друго место. Проверете ја сопствената табела на рути на гостинот, неговиот firewall и дали слушателот е врзан за очекуваната адреса. Потоа проверете ги заштитените селектори на сообраќај на VPN и локалниот пат на одговор. Секоја од нив е одделен тест со одделен резултат.

Завршете со дозволено барање на апликација и набљудувања од двата краја. Резултатот allow и точниот следен скок се два дела од доказот, а не доказ дека врската успеала.