Чаму даданне прэфікса Azure VPN разрывае злучэнне

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

Тры аб'екты, адзін з якіх трымае прэфікс

Адрасная прастора віртуальнай сеткі адказвае на іншае пытанне: што жыве ўнутры Azure. Даданне аддаленага прэфікса там не накіроўвае трафік да яго, а проста пашырае прастору, якую платформа лічыць сваёй, што можа сутыкнуцца з рэальным аддаленым дыяпазонам. Лакальны сеткавы шлюз — гэта аб'ект, які трымае аддаленыя прэфіксы, а злучэнне спасылаецца на абодва шлюзы плюс папярэдне агульны ключ.

Ёсць трэцяя заўвага, якую трэба трымаць у галаве. GatewaySubnet размяшчае кіраваныя асобнікі шлюза, павінен мець менавіта гэтую назву, а для небазавых SKU чакаецца, што ён будзе не менш за /27.

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

Чаму выдаляецца менавіта злучэнне

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

Гэтае выдаленне і ёсць прастой, таму стаўцеся да яго як да планаванай змены з пачаткам і чаканым канцом, а не як да хуткай правакі. У PowerShell паслядоўнасць кароткая: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, затым Set-AzLocalNetworkGateway з новым -AddressPrefix масівам, затым New-AzVirtualNetworkGatewayConnection з тым самым -SharedKey і тымі самымі шлюзамі. Паўторнае выкарыстанне ключа мае значэнне, бо далёкі бок не пераканфігуроўваецца, і новы ключ азначае ўзгадненне з тым, хто валодае аддаленай прыладай. Калі гэтую прыладу вядзе іншая каманда, узгадніце акно з ёй, перш чым нешта выдаляць.

Калі сам шлюз трэба перабудаваць

Другі адказ, які ходзіць вакол гэтай праблемы, кажа, што шлюз трэба стварыць нанова і абмяняць ключ. Гэта правільна для іншага набору аперацый: змена тыпу шлюза або SKU, пераход паміж пункт-да-пункта і сайт-да-сайта, або рамонт шлюза, чыя ўласная канфігурацыя няправільная. Такія змены сапраўды закранаюць рэсурс шлюза, таму перабудова сапраўды патрабуецца.

Шлюз, створаны для пункт-да-пункта, нельга проста надзяліць злучэннем сайт-да-сайта. Канфігурацыю пункт-да-пункта трэба выдаліць, а шлюз стварыць нанова, што таксама дае новы агульны ключ і новы кліенцкі пакет.

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

Чытайце стан, а не значок партала

Чытайце стан з рэсурсу, а не са значка ў партале. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 вяртае ConnectionStatus разам з лічыльнікамі байтаў на ўваходзе і выхадзе, і менавіта лічыльнікі адрозніваюць тунель, які злучаны і нічога не нясе, ад таго, які ніколі не ўстанавіўся.

Лічыльнікі, якія перастаюць расці пасярэдзіне перадачы, паказваюць на шлях, а не на аўтэнтыфікацыю. Лічыльнікі, якія ўвогуле не рухаюцца, паказваюць на набор прэфіксаў або агульны ключ.

Таймеры тлумачаць клас адключэнняў, якія памылкова прыпісваюць VPN. Балансіроўшчык нагрузкі Azure зачыняе прастойныя плыні пасля свайго настроенага тайм-аўту, па змаўчанні чатыры хвіліны, калі пісаліся гэтыя нататкі, і яго можна павялічыць, таму сервер OpenVPN на VM без keepalive можа адпадаць кожныя некалькі хвілін, пакуль усё астатняе выглядае здаровым. Шлюз, які платформа цыклічна перазапускае, таксама можа перарваць злучэнне VNet з Web App, і гэтая няўдача знаходзіцца на баку платформы, а не ў канфігурацыі кліента. Прыкмета ў тым, ці адключэнне ідзе праз фіксаваны інтэрвал ці праз змену, якую зрабілі вы.

Трымайце тры аб'екты і іх значэнні ў адным запісе: адрасную прастору віртуальнай сеткі, спіс прэфіксаў лакальнага сеткавага шлюза і спасылку на агульны ключ злучэння. артыкул PowerShell пра сайт-да-сайта дакументуе каманды лакальнага сеткавага шлюза і парадак, у якім яны павінны ісці. Параўнанне змены прэфікса з памяццю — гэта спосаб двойчы перабудаваць працоўны тунель.

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