Зашто додавање Azure VPN префикса прекида везу

Префикс додат погрешном Azure објекту ствара везу која пријављује Connected и ништа не прослеђује, а то је најскупља врста грешке у овом стеку. Укључена су три ресурса и само један од њих поседује удаљени адресни простор: гејтвеј виртуелне мреже, локални мрежни гејтвеј који описује удаљену страну и веза која их спаја. Префикс припада локалном мрежном гејтвеју, веза мора поново да се изгради да би промена ступила на снагу, а сам гејтвеј обично остаје нетакнут. Редослед није предмет преговора, а портал приказује само део њега.

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

Адресни простор виртуелне мреже одговара на друго питање: шта живи унутар Azure-а. Додавање удаљеног префикса тамо не усмерава саобраћај ка њему, само проширује простор који платформа сматра својим, што може да се судари са стварним удаљеним опсегом. Локални мрежни гејтвеј је објекат који држи удаљене префиксе, а веза реферише оба гејтвеја плус унапред подељени кључ.

Постоји и трећа резервација коју треба имати на уму. GatewaySubnet хостује управљане инстанце гејтвеја, мора да носи тачно то име, а за SKU који нису Basic очекује се да буде најмање /27.

Ништа друго не припада тој подмрежи, а промена префикса нема разлога да је дотакне. Префикс који недостаје у локалном мрежном гејтвеју недоступан је шта год да каже статус везе, јер гејтвеј нуди само оне префиксе о којима је обавештен када преговара о тунелу. Зато је симптом асиметричан: тунел је подигнут, безбедносна асоцијација је у реду, а једна подмрежа се никада не појављује у селекторима саобраћаја. Ако недостаје један удаљени опсег док суседни раде, престаните да гледате у тунел и прочитајте локални мрежни гејтвеј.

Зашто се уклања баш веза

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

То брисање је прекид, зато га третирајте као планирану промену са почетком и очекиваним крајем, а не као брзу измену. У PowerShell-у је редослед кратак: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, затим Set-AzLocalNetworkGateway са новим -AddressPrefix низом, затим New-AzVirtualNetworkGatewayConnection са истим -SharedKey и истим гејтвејима. Поновно коришћење кључа је важно, јер удаљена страна се не реконфигурише и нови кључ значи координацију са оним ко поседује удаљени уређај. Ако тим уређајем управља други тим, договорите прозор са њим пре него што било шта уклоните.

Када сам гејтвеј мора поново да се изгради

Други одговор који кружи око овог проблема каже да гејтвеј мора поново да се створи и кључ поново да се размени. То је тачно за други скуп операција: промену типа гејтвеја или SKU-а, прелазак између point-to-site и site-to-site или поправку гејтвеја чија је сопствена конфигурација погрешна. Такве промене заиста мењају ресурс гејтвеја, па је поновна изградња заиста потребна.

Гејтвеју створеном за point-to-site не може једноставно да се додели site-to-site веза. Конфигурација point-to-site мора да се уклони и гејтвеј поново створи, што такође ствара нови подељени кључ и нови клијентски пакет.

Пакет point-to-site заслужује посебну напомену јер истиче. Портал генерише датотеку кратког века, зато је практичан приступ преузети је једном и дистрибуирати уз клијентски сертификат уместо да корисницима шаљете порталски линк који ће бити мртав када кликну. За питање префикса ништа од овога не важи. Држање две процедуре одвојено је цела дисциплина: префикси су промена на нивоу везе, а својства гејтвеја су промена на нивоу гејтвеја.

Читајте стање, не значку портала

Читајте стање из ресурса, не из значке на порталу. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 враћа ConnectionStatus заједно са бројачима улазних и излазних бајтова, и управо бројачи раздвајају тунел који је повезан и ништа не преноси од оног који се никада није успоставио.

Бројачи који престану да расту на средини преноса указују на путању, не на аутентификацију. Бројачи који се уопште не померају указују на скуп префикса или подељени кључ.

Тајмери објашњавају класу прекида који се погрешно приписују VPN-у. Балансер оптерећења Azure-а затвара неактивне токове после конфигурисаног тајмаута, подразумевано четири минута када су писане ове белешке и може се повећати, зато OpenVPN сервер на VM без keepalive може да пада сваких неколико минута док све остало изгледа здраво. Гејтвеј који платформа циклично рестартује такође може да прекине VNet везу са Web App, и тај неуспех је на страни платформе, а не у клијентској конфигурацији. Знак је да ли прекид следи фиксни интервал или промену коју сте направили.

Држите три објекта и њихове вредности у једном запису: адресни простор виртуелне мреже, листу префикса локалног мрежног гејтвеја и референцу на подељени кључ везе. чланак о PowerShell-у за site-to-site документује команде локалног мрежног гејтвеја и редослед коме припадају. Поређење промене префикса са памћењем је начин на који се радни тунел поново изграђује двапут.

Затим проверите редом којим сте мењали: локални мрежни гејтвеј приказује нову листу префикса, веза је поново Connected, и бројачи се померају када пошаљете саобраћај ка домаћину у новом опсегу. Ако трећи корак не успе док прва два пролазе, удаљена страна није прихватила нови селектор саобраћаја и удаљеном уређају је потребан одговарајући унос фазе 2. То је разговор са другим крајем тунела, не још једна промена у Azure-у.