VPN S2S у Azure падключаны, але трафік не ідзе: чытаем журнал IKE

Партал піша Connected, у тунеля ёсць лічыльнік часу працы, а трасіроўка з вашай віртуальнай машыны абрываецца на другім хопе. Стан злучэння апісвае перамовы IKE і IPsec, а не тое, ці выжывае хоць адзін пакет на ўзроўні палітык з любога боку. Большасць такіх заявак тлумачаць дзве няспраўнасці, і ні адну з іх не выпраўляе змена маршруту ў Azure. Абедзве ўжо запісаны ў журнале, які стварыў шлюз, таму я пачынаю адтуль, а не з табліцы маршрутаў.

Што насамрэч пацвярджае Connected

Падключанае злучэнне site-to-site азначае, што фазы 1 і 2 завершаны і асацыяцыі бяспекі ўзнятыя. Гэта сцверджанне пра перамовы: абодва бакі дамовіліся пра прапанову, абмяняліся ключамі і ўсталявалі пару SA. Яно нічога не кажа пра тое, ці селектары трафіку адпавядаюць падсеткам, якія вы лічыце абароненымі, і нічога пра тое, ці будзе далёкі бок куды-небудзь маршрутызаваць пакет пасля расшыфроўкі. Тунель можа стаяць тыднямі, скідваючы кожны цікавы паток, і гэта менавіта той узор, з-за якога людзі перабудоўваюць здаровы шлюз.

Дзве няспраўнасці, якія варта праверыць першымі: бок, які прапануе AH замест ESP, і віртуальная сетка, пранумараваная ў прасторы, якую шлюз не лічыць унутранай.

Адкрыйце экспартаваны журнал, перш чым чапаць маршруты

У партале адкрыйце шлюз віртуальнай сеткі і запусціце аперацыю VPN troubleshoot для злучэння, затым спампуйце створаны пакет і распакуйце яго. Унутры журнал IKE з абменамі фаз 1 і 2, з адзнакамі часу і чытэльны як звычайны тэкст. Шукайце ў ім радок transform, а не чытайце зверху ўніз, бо цікавы запіс звычайна знаходзіцца праз некалькі сотняў радкоў. Калі доступу да партала няма, тая ж дыягностыка з’яўляецца ў прызначэнні журнала шлюза, калі ўключаны параметры дыягностыкі.

Два запісы нясуць асноўную каштоўнасць. Першы гучыць прыкладна так: expected ESP with combined authentication and cipher, received AH. Другі — памылка invalid payload падчас абмену IKE, што звычайна азначае няслушнае або непадтрыманае поле прапановы.

Абодва апісваюць, што прапанавала лакальная прылада, таму абодва — налады на баку партнёра. Перастварэнне боку Azure не змяняе прапанову, якую адпраўляе ваш файрвол, і рабіць гэта ўсё роўна — самая частая марна патрачаная гадзіна ў гэтым працэсе. На баку партнёра пастаўце фазу 2 на ESP з аб’яднанай аўтэнтыфікацыяй і шыфраваннем і дайце яму дамовіцца пра алгарытм, затым праверце, ці сцяжок пастаўшчыка з назвай накшталт combined mode моўчкі не выбірае прапанову AH.

Пацвердзіце адрасную прастору віртуальнай сеткі

Шлюз чакае, што віртуальная сетка будзе ў прыватных дыяпазонах. Сетка, пранумараваная ў публічным блоку, напрыклад тая, што пачынаецца з 111.x, можа ўзняць тунель, але Azure адмовіцца лічыць гэтую прастору ўнутранай, таму злучэнне выглядае здаровым, а ні адзін паток не прымаецца. Пацвердзіце адрасную прастору, перш чым праводзіць паўдня над селектарамі. Калі нумарацыя — жорсткае патрабаванне старога размеркавання, выпраўленне — змена адраснага плана, а не іншы шлюз.

Запішыце перакрыццё з лакальнымі дыяпазонамі, пакуль вы ў калонцы адраснай прасторы, бо перакрыжаваныя прэфіксы даюць іншую няспраўнасць, якая з кліента выглядае падобна.

Праверце прэфіксы ў абодвух напрамках

Рэсурс шлюза лакальнай сеткі захоўвае лакальныя прэфіксы, і яны павінны адпавядаць падсеткам, якія далёкая прылада насамрэч абараняе. Зводка, якая ўключае адрасы, што прылада скідвае, прапусціць адны паткі і праваліць іншыя, і гэта чытаецца як перарывістая няспраўнасць маршрутызацыі, а не як неадпаведнасць канфігурацыі. Праверце і далёкі бок: адзін канец паказвае /16, а другі — тры /24 унутры яго, гэта класічная частковая няўдача. Ні адзін спіс не з’яўляецца аўтарытэтным сам па сабе, таму параўноўвайце іх побач, а не давярайце таму, які бачыце.

Змена прэфікса не заўсёды падхопліваецца сама, таму плануйце перазахаваць або перастварыць аб’ект злучэння, а затым пацвердзіце, што новыя прэфіксы з’явіліся з абодвух бакоў.

Тэстуйце шлях, а не ping

Трасіроўка, якая аддзяляе працоўны тунель ад працоўнага маршруту, выглядае так: першы хоп — лакальны шлюз, затым некалькі моўклых хопаў, затым далёкі хост адказвае. Калі трасіроўка ніколі не даходзіць да хоста, праверце порт TCP, які рэальна выкарыстоўвае праграма, бо ICMP фільтруецца дастаткова часта, каб няўдалы ping амаль нічога не даказваў. Запусціце тую ж трасіроўку з далёкага хоста да віртуальнай машыны ў Azure. Асіметрыя паміж двума вынікамі — самы хуткі спосаб знайсці адсутны зваротны маршрут або правіла, якое дазваляе толькі адзін напрамак.

Запішыце прапанову партнёра, абедзве адрасныя прасторы і час стварэння злучэння ў заяўку, каб наступны інжынер ведаў, якія значэнні перабудоўвалі, а якія не чапалі.

Калі журнал прыходзіць пустым, магчыма, шлюз наогул не тэрмінуе ваша злучэнне. Пацвердзіце, што адрас партнёра ў шлюзе лакальнай сеткі адпавядае прыладзе, з якой вы чытаеце журнал, бо два шлюзы ў адной падпісцы лёгка пераблытаць падчас перабудовы. Гэтая памылка каштуе дня і не пакідае слядоў ні ў якім журнале.