Две преносни сметачи се автентицираат на истата Azure point-to-site порта, и само еден стигнува до новоповрзаниот VNet. Двата покажуваат Connected, значи автентикацијата не е разликата; разликата се рутите до одредиштето што ги држат. Започнете од клиентот што не успева, споредете едно одредиште и само потоа одлучете дали празнината им припаѓа на пакетот на портата или на локалната табела на рути.

Започнете од клиентот што не успева, не од портата

Потврдете ја топологијата пред да го обвините преносниот сметач. Проверете кои VNet се поврзани со VNet на портата и дали новата мрежа е директно peered или се стигнува преку одделен site-to-site тунел. Ако новиот VNet воопшто не е поврзан со VNet на портата, ниту еден клиентски пакет не може да рутира кон него, а работниот преносен сметач е аномалијата што треба да се објасни. Запишете го одговорот, зашто тој одлучува дали дебагирате клиент или порта.

Кога топологијата е во ред, ставете ги двата преносни сметачи еден до друг. Иста порта, ист базен адреси, ист протокол и иста верзија на клиентот се споредбата што ја сакате; сè друго е втора променлива што подоцна ќе треба да ја отстраните.

Споредете едно одредиште со route print

Изберете дозволена IP на ресурс и споредете ги двата преносни сметачи двапати: исклучени, потоа поврзани. Во Windows route print -4 ги наведува IPv4 рутите со префикс на одредиштето, интерфејс, следен скок и метрика. Запишете го редот што навистина би победил за тоа одредиште наместо да броите записи што го содржат зборот VPN.

Изборот е прво најдолг префикс, потоа метрика, така што поконкретна локална рута може да ја победи тунелската рута без да изгледа погрешно. Ако предвиденото одредиште е во 10.24.0.0/16, здрав клиент прикажува соодветна рута на VPN интерфејсот, додека клиентот што не успева ја испраќа истата адреса до својата стандардна порта.

Конфликтниот локален префикс може да го даде истиот симптом. Пред да додадете нешто, одлучете кој од двата случаи го имате: воопшто нема тунелска рута, или тунелска рута што губи од поконкретна.

TTL expired не е грешка во дистрибуцијата на рути

Ping што враќа TTL expired in transit вели дека пакетот го потрошил својот квота на скокови, што обично значи јамка на препраќање, а не расипан VPN драјвер. Windows ping прифаќа TTL до 255, а покачувањето на вредноста не поправа јамка; само ја одложува истата грешка. Третирајте ја пораката како симптом на патеката, не како доказ за дистрибуцијата на рути.

Користете tracert -4 10.24.1.10 за да видите каде патеката се повторува. Ако истите два скока се појавуваат одново и одново, побарајте рута што сообраќајот наменет за тунелот го враќа назад во тунелот или во локален рутер што го препраќа назад.

Регенерирајте го пакетот на портата што го поседува

Microsoft документира дека Windows клиентските пакети мора повторно да се преземат и инсталираат по релевантни тополошки промени. Земете го тековниот пакет од Azure портата што го служи овој профил, потоа применете го со поддржаниот процес за тој клиент. Замената на извршна датотека на неповрзана VPN апликација не е иста операција како регенерирање на поставки специфични за портата. Повторното преземање на пакетот е евтино; погодувањето локални рути не е.

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

Сценаријата за рутирање на Azure P2S ги одделуваат директно peered VNet од мрежи достапни преку други тунели, а нов пакет не може да го направи peering-от транзитивен. Некои Windows site-to-site или BGP сценарија бараат и рачно конфигурирани оддалечени рути, така што освежувањето на пакетот не е универзален механизам за дистрибуција на рути.

Задржете привремена рута привремена

Рачна рута може да изолира рута што недостасува кај клиентот, но изградете ја од вистинскиот дизајн: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, без постојаното знаменце, за да исчезне при рестарт. Изберете индекс на интерфејс и следен скок од поврзаниот VPN адаптер, а не од претпоставка.

Не оставајте експериментална рута како постојан конкурентски сопственик. Идните ажурирања на профилот може да го додадат истиот префикс со друга метрика и тогаш рачниот запис тивко одлучува која патека победува. Запишете го чекорот за отстранување во промената.

Кога правилната рута е активна, тестирајте ја целната апликација наместо ping. Ако пакетите стигнат до Azure, но услугата сè уште не успева, проверете ја мрежната безбедносна група и повратната патека, бидејќи тие се одделени од тоа дали преносниот сметач го научил префиксот.

Поврзани статии