Защо връзката точка към сайт се нуждае от маршрутно базиран шлюз Azure VPN

Базираният на правила шлюз изгражда IPsec тунел, избиран от селектори на трафик, и няма интерфейс, на който да предаде клиентските маршрути. Връзката точка към сайт е функция за маршрутизация: шлюзът притежава пул от клиентски адреси и инсталира маршрути към тези клиенти във виртуалната мрежа. Именно това несъответствие е причината порталът да не показва опция за добавянето ѝ. Нищо в съществуващия шлюз не може да се превключи, за да създаде интерфейса, затова промяната е подмяна, а не редакция на конфигурацията.

Редът е по-важен от отделните стъпки. Сбъркайте последователността и престоят на връзката сайт към сайт ще надхвърли прозореца за поддръжка.

Какво всъщност прави базираният на правила шлюз

Базираният на правила шлюз съпоставя пакетите със селекторите на трафик, конфигурирани за връзката, и изпраща съвпаденията в един тунел. Няма тунелен интерфейс с адрес и никъде във виртуалната мрежа не се появява маршрут за отделен клиент. Таблицата за маршрути просто получава локалните префикси, сочещи към шлюза. Този модел е достатъчен за връзка сайт към сайт между две фиксирани адресни пространства.

Маршрутно базираният шлюз работи обратно: той предоставя тунелен интерфейс и маршрутите решават какво влиза в него. Връзката точка към сайт и всеки дизайн, чийто набор от партньори се променя, зависят от съществуването на този интерфейс.

Защо клиентският пул се нуждае от този интерфейс

Когато лаптоп се свърже, шлюзът му назначава адрес от пула точка към сайт. След това виртуалната мрежа се нуждае от маршрут, който казва, че този адрес е достъпен през шлюза. Без тунелен интерфейс няма към какво да се прикачи този маршрут.

Пулът идва от диапазон, който вие определяте, и шлюзът разпределя от него. Ако този диапазон се припокрива с локалната мрежа или с партньорска виртуална мрежа, конфликтът се появява едва след свързване на клиент, което е лош момент да го откриете. Резервирайте пула преди началото на миграцията.

Типът също не е настройка за отделна връзка. Един шлюз има един тип и всяка връзка, която той поддържа, се държи съответно, затова смесеният дизайн се нуждае от втори шлюз, а не от втора връзка.

Типът е фиксиран при създаването

Microsoft посочва, че шлюз на виртуална мрежа не може да бъде променян между базиран на правила и базиран на маршрути след разгръщане. Няма команда за преобразуване и няма превключвател в портала. Създаването на втори шлюз в същата подмрежа също не е заобиколен път, защото Azure позволява един шлюз на виртуална мрежа. Затова миграцията е премахване, изграждане наново и повторно свързване.

Това вгражда и решението за SKU в същото изграждане. Преминаването към по-голям SKU по-късно е още една подмяна на шлюз с още един престой.

Един шлюз, една GatewaySubnet

Шлюзът живее в подмрежа с име GatewaySubnet и само един шлюз я заема. Оразмеряването на тази подмрежа е част от подготовката, защото по-голям SKU изисква повече адреси, а подмрежа не може да бъде намалена след това. Запишете текущите настройки сайт към сайт, споделения ключ, шлюза на локалната мрежа и ефективните маршрути, преди да пипате нещо. След това третирайте прозореца като престой, защото тунелът сайт към сайт остава изключен, докато не се конфигурира новата връзка.

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

Какво подмяната не поправя

Второ ограничение принадлежи на партньора, а не на Azure. Локално устройство, базирано на правила, може да достигне само виртуалната мрежа, към която се свързва, и не може да транзитира към други локални мрежи или други виртуални мрежи през същия шлюз. Подмяната на страната Azure не променя какво партньорът може да избере.

Ако изискването наистина е транзит между сайтове, отговорът е маршрутно базирано партньорско устройство или топология, в която всяка дестинация завършва отделно. Уредете това, преди да обещавате дата, защото само подмяната на шлюза няма да го осигури.

Ред на операциите и проверките

Проверявайте всяка възможност поотделно. Първо състоянието на тунела сайт към сайт и една заявка хост към хост, после връзка точка към сайт и един частен ресурс, после всеки транзитен път, който дизайнът твърди. Зеленият статус на шлюза доказва само, че асоциацията за сигурност е установена, и нищо повече. Пазете проверките в този ред, за да сочи всеки отказ към етапа, който го е внесъл.

Регенерирайте клиентските пакети след всяка промяна на топологията и дръжте пула далеч от всеки локален и партньорски диапазон. Ограниченията и разликите между SKU са събрани в справката за настройки на Azure VPN Gateway.