Azure S2S VPN е поврзан, но нема сообраќај: прочитајте го IKE дневникот

Порталот вели Connected, тунелот има бројач на време на работа, а trace од вашата виртуелна машина умира на вториот hop. Состојбата на врската ја опишува IKE и IPsec преговарањето, а не дали еден пакет преживува слојот на политики на која било страна. Две грешки објаснуваат повеќето од овие тикети и ниту една не се поправа со менување на Azure рута. И двете веќе се запишани во дневникот што го создаде портата, затоа почнувам оттаму, а не од табелата со рути.

Што всушност потврдува Connected

Поврзана site-to-site врска значи дека фаза 1 и фаза 2 се завршени и безбедносните асоцијации се активни. Тоа е изјава за преговарањето: двете страни се договориле за предлог, размениле клучеви и инсталирале пар SA. Таа не кажува ништо за тоа дали селекторите на сообраќај се совпаѓаат со подмрежите што ги сметате за заштитени, ниту дали далечната страна ќе го рутира пакетот некаде по дешифрирањето. Тунелот може да стои со недели додека го фрла секој интересен тек, и токму оваа шема ги тера луѓето да изградат здрава порта одново.

Двете грешки што вреди прво да се проверат се peer што предлага AH наместо ESP, и виртуелна мрежа нумерирана во простор што портата нема да го третира како внатрешен.

Отворете го извезениот дневник пред да ги допрете рутите

Во порталот отворете ја портата на виртуелната мрежа и стартувајте ја операцијата VPN troubleshoot врз врската, потоа преземете го пакетот што го создава и отпакувајте го. Внатре е IKE дневник со размените на фаза 1 и фаза 2, со временски ознаки и читлив како обичен текст. Барајте во него линијата transform наместо да читате од горе надолу, зашто интересниот запис обично е неколку стотини линии подолу. Ако немате пристап до порталот, истата дијагностика се појавува во одредиштето на дневникот на портата кога се вклучени дијагностичките поставки.

Два записи го носат најголемиот дел од вредноста. Првиот звучи приближно expected ESP with combined authentication and cipher, received AH. Вториот е грешка за невалиден payload за време на IKE размената, што обично значи погрешно форматирано или неподдржано поле на предлог.

И двете опишуваат што понудил локалниот уред, значи и двете се поставки на страната на peer. Повторното генерирање на Azure страната на врската не го менува предлогот што го праќа вашиот firewall, и да го правите тоа сепак е најчесто потрошениот час во оваа постапка. На peer поставете ја фаза 2 на ESP со комбинирана автентикација и шифра и оставете го да преговара за алгоритмот, потоа проверете дали квадратчето на добавшувачот со име како combined mode тивко избира AH предлог под него.

Потврдете го адресниот простор на виртуелната мрежа

Портата очекува виртуелната мрежа да биде во приватни опсези. Мрежа нумерирана во јавен блок, на пример онаа што почнува со 111.x, може да го крене тунелот додека Azure одбива да го третира тој простор како внатрешен, па врската изгледа здрава и ниту еден тек не е прифатен. Потврдете го адресниот простор пред да потрошите попладне на селекторите. Ако нумерацијата е тврдо барање од постара распределба, поправката е промена на адресниот план, а не друга порта.

Запишете го преклопувањето со локалните опсези додека сте во панелот за адресен простор, зашто преклопувачките префикси создаваат поинаков дефект што од клиентот изгледа слично.

Проверете ги префиксите во двете насоки

Ресурсот на портата на локалната мрежа ги држи локалните префикси и тие мора да одговараат на подмрежите што далечниот уред навистина ги штити. Резиме што вклучува адреси што уредот ги фрла ќе пропушти некои текови, а на други ќе падне, што се чита како повремен дефект во рутирањето, а не како несовпаѓање во конфигурацијата. Проверете ја и далечната страна: едниот крај наведува /16, а другиот наведува три /24 во него — тоа е класичниот делумен неуспех. Ниту една листа не е сама по себе меродавна, затоа споредете ги една до друга наместо да ѝ верувате на онаа што ја гледате.

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

Тестирајте пат, не ping

Trace што разликува тунел што работи од рута што работи изгледа вака: првиот hop е локалната порта, потоа неколку hop без одговор, потоа одговара далечниот host. Ако trace никогаш не стигне до host, тестирајте го TCP портот што апликацијата навистина го користи, зашто ICMP се филтрира доволно често што неуспешен ping докажува многу малку. Пуштете го истиот trace од далечен host кон виртуелна машина во Azure. Асиметријата меѓу двата резултата е најбрзиот начин да најдете маршрута за враќање што недостасува или правило што дозволува само една насока.

Запишете го предлогот на peer, двата адресни простори и времето на создавање на врската во тикетот, за да знае следниот инженер кои вредности се обновени, а кои никогаш не биле допрени.

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