Защо добавянето на префикс за Azure VPN прекъсва връзката

Префикс, добавен към грешен обект в Azure, създава връзка, която съобщава Connected и не предава нищо, а това е най-скъпият вид грешка в този стек. Замесени са три ресурса и само един от тях притежава отдалеченото адресно пространство: шлюзът на виртуалната мрежа, локалният мрежов шлюз, който описва далечната страна, и връзката, която ги свързва. Префиксът принадлежи на локалния мрежов шлюз, връзката трябва да бъде изградена наново, за да влезе промяната в сила, а самият шлюз обикновено остава недокоснат. Редът не подлежи на обсъждане и порталът показва само част от него.

Три обекта, един от които държи префикса

Адресното пространство на виртуалната мрежа отговаря на друг въпрос: какво живее вътре в Azure. Добавянето на отдалечен префикс там не насочва трафик към него, а само разширява пространството, което платформата смята за свое, което може да се сблъска с реалния отдалечен диапазон. Локалният мрежов шлюз е обектът, който държи отдалечените префикси, а връзката реферира двата шлюза плюс предварително споделен ключ.

Има и трета резервация, която трябва да се държи сметка. GatewaySubnet хоства управляваните инстанции на шлюза, трябва да носи точно това име и за не-Basic 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.