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

Префикс додаден на погрешен Azure објект создава врска што пријавува Connected и не препраќа ништо, а тоа е најскапиот вид грешка во овој стек. Вклучени се три ресурси и само еден од нив го поседува далечниот адресен простор: портата на виртуелната мрежа, локалната мрежна порта што ја опишува далечната страна и врската што ги поврзува. Префиксот и припаѓа на локалната мрежна порта, врската мора повторно да се изгради за промената да стапи на сила, а самата порта обично се остава недопрена. Редоследот не е предмет на преговори, и порталот покажува само дел од него.

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

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

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