Дали на Azure VNet поврзана со peering ѝ треба сопствена VPN порта?

Се појавува нов spoke VNet, hub-от веќе има работна site-to-site порта, а очигледното прашање е дали треба да платите за втора порта. Обично не: транзитот на порта ѝ овозможува на spoke да ја користи портата на hub-от преку peering. Три услови одлучуваат дали ќе работи, и ниту еден не се гледа од значката за состојба на peering. Поврзаноста на peering и дозволата да се користи туѓа порта се одделни поставки, така што две VM што веќе можат да се пингуваат не докажуваат ништо за VPN патеката.

Прв услов: портата и нејзиното отсуство во spoke

Azure го поддржува транзитот на порта за SKU на VPN Gateway освен Basic, и може да го носат и регионален и глобален peering. Spoke троши порта што не ја поседува, па не може да има своја: ако во spoke веќе постои порта или веќе е избрана опција за оддалечена порта, поставката за транзит што ја сакате ќе биде недостапна или неефикасна. Проверете го тоа пред да отстранувате грешки, зашто оневозможеното поле за избор е симптом, а не дефект. Прво прочитајте го SKU-то и постојната порта, потоа погледнете ги поставките за peering.

Не бришете постојна порта на spoke за да се појави опцијата, сѐ додека не знаете што зависи од неа. Редоследот на миграција е поважен од полето за избор.

Втор услов: една поставка во секој правец на peering

Peering се два објекта, по еден на секој VNet, и поставките за транзит живеат на различни страни од тој пар. Peering-от на hub-от кон spoke мора да ѝ дозволи на портата на hub-от да го опслужува spoke; peering-от на spoke кон hub-от мора да ја прифати портата на hub-от. Водичот за транзит на порта на Microsoft ги именува по правец, и тоа е единствениот начин да ги одржите точни:

Контрола означена со remote го менува значењето зависно од тоа чиј peering уредувате, затоа читајте го правецот, а не зборот. Поставете ги двете страни, зачувајте и потврдете дека peering-от пријавува поврзаност на двете места.

Трет услов: адресен простор и граници на дозволи

Транзитот не може да направи истиот префикс на одредиште да значи две мрежи, затоа опсезите на hub-от, spoke и локалната мрежа мора да бидат разделени пред нешто од ова да работи. VNet-овите може да бидат и во различни претплати или различни закупци; тоа не е забрана, но идентитетот што го создава или ажурира секој peering треба да ги има потребните дозволи на таа мрежа. Промените меѓу претплати честопати паѓаат на дозволи, а грешката лесно се чита погрешно како проблем со топологијата.

Запишете ги опсезите и сопствениците пред промената. Погодувањето за било кое од двете дава peering што се поврзува и ништо не рутира.

Проверувајте со ефективни рути, а не со состојба на peering

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

Тестирајте една услуга од работното оптоварување во spoke и следете го одговорот. Тестот од VPN портата или од VM во hub-от применува различен изворен префикс и различна патека.

Ако топологијата опслужува и point-to-site клиенти, одделно валидирајте ги нивните инсталирани рути. Клиентските пакети за Windows може да бараат регенерирање по промена на топологијата, и тоа е задача за рутирање на клиентот, а не доказ дека споделувањето на портата не успеало.

Што не дава споделувањето на порта

Транзитот на порта е удобност за рутирање, не авторизација. Мрежните безбедносни групи, локалните филтри и правилата на ниво на услуга сѐ уште одлучуваат до што може да стигне работното оптоварување во spoke, затоа овозможете ја конкретната услуга од извор до одредиште наместо да претпоставите дека споделениот тунел дозволува сѐ зад него.

Peering-от исто така не е транзитивен онака како што луѓето се надеваат. Додавањето уште еден spoke или приватна крајна точка внесува свои барања за рутирање и пристап што постојната поставка за транзит не ги покрива.