Планирайте частните адресни диапазони за VPN, преди сайтовете да се сблъскат

Два сайта, които и двата използват 192.168.1.0/24, могат да стигат до интернет и въпреки това да не се стигат един друг. Шлюзът не връща грешка; той инсталира един маршрут за този префикс и изпраща всеки пакет към партньора, който го е заявил пръв. Нищо в ръкостискането, списъка с шифри или метриката на интерфейса не казва кой партньор е сгрешен. Планирането на адреси е частта от дизайна, която решава това, преди някой да се свърже.

Направете опис на всяко пространство, което трябва да е достъпно

Запишете диапазоните, които трябва да се маршрутизират, не само тези, които конфигурирате. Това означава локални мрежи на сайтове, клиентски пулове за VPN, облачни подмрежи, мрежи за управление и извънлентови мрежи, лабораторни сегменти и мрежите, от които потребителите обичайно се свързват у дома. Потребителски рутер, който се доставя като 192.168.1.0/24, не е хипотетичен, а същият префикс се среща в хотели и конферентни зали. Описът е таблица от префикс, собственик и предназначение и е единственият артефакт, който спира един и същ диапазон да бъде раздаден два пъти.

Добавете префиксите, които очаквате през следващата година, защото план, който покрива само днес, се проваля при първия нов сайт. Отбележете във всеки ред кой може да го промени, а не само кой го притежава.

Точно повторното използване прави това трудно: частното пространство е ограничено и всяка организация смята 10.0.0.0/8 за свое. Планът не може да обещае, че бъдеща гостуваща мрежа няма да попадне на един от вашите префикси, затова дизайнът трябва да казва какво се случва, когато това стане. Две правила вършат по-голямата част от работата. Поставете клиентските пулове в един непрекъснат блок, който можете да обобщите, и никога не разпределяйте диапазон, който друг екип вече маршрутизира. Всичко останало е запис, който някой поддържа актуален.

Защо припокриването побеждава таблицата за маршрутизация

Маршрутът е префикс плюс следващ хоп и препращането избира най-дългия съвпадащ префикс. Когато двама партньори заявят един и същ 192.168.1.0/24, таблицата държи един запис за него, така че трафикът за двата сайта излиза през един и същ тунел. Вторият сайт не е конфигуриран грешно; той е недостъпен, защото първият отговаря за същите адреси. Никаква метрика не може да ги раздели, защото съвпадението става преди метриките да бъдат питани.

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

Определете съзнателно размера на клиентския пул и диапазоните на сайтовете

Клиентският пул за VPN е диапазон, който шлюзът раздава адрес по адрес, така че размерът му ограничава едновременността. /24 съдържа 254 използваеми адреса, което е щедро за малък екип и тясно за клон, който пуска контейнери; /22 не струва нищо допълнително в частното пространство и премахва спора. Дръжте пула непрекъснат и далеч от всяка локална мрежа на сайт, за да не погълне обобщеният маршрут към клиентите някой сайт. Резервирайте диапазона дори докато пулът е празен, защото неописаният диапазон е този, който следващият инженер ще разпредели.

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

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

Транслацията и преномерирането решават различни проблеми

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

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

Тествайте от далечната страна, преди да внедрите

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

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

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