Защо копирането на конфигурацията на OpenVPN сървър във филиал не работи

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

Третирането на филиала като партньор със собствена идентичност и мрежова роля е това, което прави профила правилен. Поправката не е по-добро копие и останалата част от страницата е за това какво трябва действително да държи клиентът.

Две роли, които изглеждат като един файл

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

Файлът на сървъра съдържа директиви, които нямат смисъл за клиент: адрес за обвързване и порт за слушане, пул от адреси за раздаване и често списък за изтласкване на настройки, които клиентите трябва да получат. Копирането им във филиал създава устройство, което се опитва да бъде едновременно слушател и клиент.

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

Какво трябва да съдържа профилът за филиал

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

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

Внимавайте с работните процеси на устройствата. Пакетът Client Export на pfSense създава профили за подходящи контексти на Remote Access и неговият списък със сървъри включва само сървъри, настроени в режим Remote Access. Сървър „обект към обект“ от друг режим не се появява и това отсъствие е информация, а не покана да копирате тайните на сървъра.

Ако устройството не експортира нужния профил, използвайте документирания му работен процес за клиент „обект към обект“ или изградете профила от поддържания пример на инсталираното издание. Експортирайте резервно копие на сървъра към филиала само ако планът е възстановяване на сървър, а той не е такъв. Копието носи и частния материал на центъра, затова преместването му във филиал е решение за работа с ключове, а не пренос на файл. Дръжте го в центъра и създавайте идентичността на клиента там, където се издават сертификати.

Връзката между партньора и мрежата е отделна

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

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

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

Как да докажете, че филиалът е партньорът, който мислите

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

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

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

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