Зошто поврзувањето од точка до локација бара Azure VPN порта заснована на рути

Портата заснована на правила гради IPsec тунел избиран од селектори на сообраќај и нема интерфејс на кој би му ги предала клиентските рути. Поврзувањето од точка до локација е функција на рутирање: портата поседува базен на клиентски адреси и во виртуелната мрежа поставува рути кон тие клиенти. Токму тоа несогласување е причината порталот да не прикажува опција за негово додавање. Ништо на постојната порта не може да се префрли за да го создаде интерфејсот, затоа промената е замена, а не уредување на конфигурацијата.

Редоследот е поважен од поединечните чекори. Ако ја погрешите низата, прекинот меѓу локациите ќе го надмине прозорецот за одржување.

Што навистина прави портата заснована на правила

Портата заснована на правила ги совпаѓа пакетите со селекторите на сообраќај конфигурирани на врската и совпаѓањата ги испраќа во еден тунел. Нема тунелски интерфејс со адреса и никаде во виртуелната мрежа не се појавува рута за поединечен клиент. Табелата со рути едноставно ги добива локалните префикси што покажуваат кон портата. Тој модел е доволен за врска меѓу локации помеѓу два фиксни адресни простори.

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

Зошто на базенот на клиенти му треба тој интерфејс

Кога ќе се поврзе преносен сметач, портата му доделува адреса од базенот од точка до локација. Потоа на виртуелната мрежа ѝ треба рута што вели дека оваа адреса е достапна преку портата. Без тунелски интерфејс нема за што да се прикачи таа рута.

Базенот доаѓа од опсег што вие го одредувате, а портата доделува од него. Ако тој опсег се преклопува со локалната мрежа или со спарена виртуелна мрежа, конфликтот се појавува само откако ќе се поврзе клиент, што е лош момент да се открие. Резервирајте го базенот пред да започне миграцијата.

Ниту типот не е поставка по врска. Една порта има еден тип и секоја врска што ја држи се однесува соодветно, затоа мешаниот дизајн бара втора порта, а не втора врска.

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

Microsoft наведува дека портата на виртуелна мрежа не може да се смени помеѓу заснована на правила и заснована на рути по распоредувањето. Нема команда за претворање и нема прекинувач во порталот. Создавањето втора порта во истата подмрежа исто така не е решение, бидејќи Azure дозволува една порта по виртуелна мрежа. Затоа миграцијата е отстранување, повторно изградување и повторно поврзување.

Тоа ја вклучува и одлуката за SKU во истото изградување. Преминот на поголем SKU подоцна е уште една замена на порта со уште еден прекин.

Една порта, една GatewaySubnet

Портата живее во подмрежа наречена GatewaySubnet и само една порта ја зазема. Одредувањето на големината на таа подмрежа е дел од подготовката, бидејќи поголем SKU бара повеќе адреси, а подмрежата не може подоцна да се намали. Запишете ги тековните поставки меѓу локации, споделениот клуч, портата на локалната мрежа и ефективните рути пред да допрете нешто. Потоа третирајте го прозорецот како прекин, бидејќи тунелот меѓу локации останува исклучен додека не се конфигурира новата врска.

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

Што не поправа замената

Второто ограничување му припаѓа на партнерот, а не на Azure. Локален уред заснован на правила може да достигне само виртуелната мрежа со која е поврзан и не може да транзитира кон други локални мрежи или други виртуелни мрежи преку истата порта. Замената на страната на Azure не го менува тоа што партнерот може да го избере.

Ако барањето навистина е транзит меѓу локации, одговорот е партнерски уред заснован на рути или топологија во која секоја дестинација завршува одделно. Решете го тоа пред да ветите датум, бидејќи самата замена на портата нема да го обезбеди.

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

Проверете ја секоја можност одделно. Прво статусот на тунелот меѓу локации и едно барање од домаќин до домаќин, потоа врска од точка до локација и еден приватен ресурс, потоа секоја транзитна патека што ја тврди дизајнот. Зелениот статус на портата докажува само дека безбедносната асоцијација се подигнала и ништо повеќе. Држете ги проверките во тој редослед за да покаже дефектот на фазата што го внела.

Регенерирајте ги клиентските пакети по секоја промена на топологијата и држете го базенот подалеку од секој локален и спарен опсег. Ограничувањата и разликите меѓу SKU се собрани во референцата за поставки на Azure VPN Gateway.