Два активни тунела IPsec все още се нуждаят от план за обратен път

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

Начертайте четири шлюза, преди да начертаете маршрут

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

Тази таблица е дизайнът. Всичко след нея е въпрос дали устройствата са съгласни с таблицата.

Как се избира пътят напред

Слой за многопътно маршрутизиране с равен разход разпределя потоците по следващи хопове чрез хеширане на полета от заглавката, което RFC 2992 описва подробно. Този избор може да е напълно безсъстоятелен: не му е нужен запис за проследяване на връзка, а само стабилен хеш върху непроменени полета. Дръжте набора от пътища и входните данни на хеша постоянни и всеки пакет от потока избира същия следващ хоп.

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

От какво всъщност има нужда обратният път

Тук разходката престава да бъде симетрична. Стабилният хеш напред не ви казва нищо за това какво ще направи далечният сайт с отговора. Ако независима защитна стена трябва да вижда двете посоки на връзката, за да поддържа полезно състояние, обратен маршрут, който я заобикаля, оставя трафик, който не съвпада с нищо. Две кутии с подобни набори от правила не са споделено състояние.

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

Къде транслацията решава вместо вас

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

Ако изискването е просто двата пътя да носят трафик и всеки един да оцелее при загуба на доставчик, обикновено по-малкият дизайн е многопътност по поток със съгласувано обратно маршрутизиране.

Извървете приемането по ред

Тествайте в тази последователност и записвайте адресите на всяка стъпка: нова връзка по път A и нейният обратен път, същото по път B, после загуба на един доставчик, после възстановяване. За всеки резултат отбележете кои установени потоци са се преместили, кои са трябвало да се свържат наново и къде са отишли новите потоци след това. Запишете очакваната стойност първо, после я сравнете със захвата. Два установени тунела не доказват нищо от това.

Дизайнът е готов, когато таблицата, която сте написали, съвпада с това, което показва захватът, а не когато двата тунела са вдигнати.