Планирайте подмрежите преди VPN между сайтове: преномериране или транслация

Два офиса използват 192.168.1.0/24, защото никой не е планирал друго, а от тунела се очаква да го реши. Той не може: рутер не може да накара един и същ частен адрес да означава две различни места. Работата, която предотвратява това, се случва преди първият параметър на тунела да бъде въведен.

Инвентаризирайте всеки диапазон, включително забравените

Съберете LAN мрежите, сървърните сегменти, пуловете от клиенти за отдалечен достъп, диапазоните на облачните VPC и всякакви контейнерни или overlay мрежи, до които хостовете трябва да достигат. Клиентските пулове са тези, които хората забравят, и те се припокриват с офис диапазон изненадващо често, защото и двата са избрани от една и съща стойност по подразбиране. Включете управляващата мрежа и всеки out-of-band сегмент.

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

Правете IPv6 отделно, защото неговият план и неговите припокривания са независими.

Сравнявайте префикси, не познати адреси

Две мрежи с различни адреси на хостове все още могат да се припокриват, защото припокриването е свойство на маските, а не на числата, които хората помнят. 10.20.0.0/16 съдържа 10.20.30.0/24, независимо дали някой го казва на глас. Сравнявайте пълни двойки префикси и проверявайте агрегатите срещу по-малките мрежи в тях. Затова проверката принадлежи в електронна таблица, а не в нечия глава.

Същата проверка важи за собствения клиентски пул на VPN и за всеки транслейтнат диапазон, който планирате да въведете, тъй като транслейтнат диапазон, който се сблъсква, е по-лош от първоначалното припокриване.

Таблица с префикси и маски е достатъчна; диаграма без маски — не.

Решете какво наистина трябва да премине

Един сайт може да съдържа тридесет подмрежи, докато една сервизна мрежа се нуждае от отдалечен достъп. Започнете от това изискване и анонсирайте само каквото то изисква, защото по-малките анонси и съответстващите правила за достъп са по-лесни за преглед и по-трудни за случайно разширяване. Анонсирането на всеки използван частен диапазон е навик, който превръща тунела в мост. Колкото по-тесен е анонсът, толкова по-малък е радиусът на щетите от бъдеща грешка.

Частният DNS трябва да връща адреси, до които предвидените клиенти могат да достигнат, така че име, сочещо към неанонсиран или припокриващ се диапазон, остава счупено дори когато справката успее.

Напишете списъка за достъп преди конфигурацията на тунела, а не след като тя се провали.

Преномериране или транслация и познайте цената

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

Което и да изберете, документирайте както оригиналния, така и представения адрес, защото всеки следващ разговор за отстраняване на проблеми се нуждае от тях.

Заобиколно решение без обратен път не е заобиколно решение.

Използвайте матрица на маршрутите като приемен тест

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

Ping между адресите на тунела доказва, че тунелът съществува, и нищо за плана на адресите зад него.

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