Един VPN профил на два сървъра: три регистъра на състоянието
Споделеният достъп, мрежовата конфигурация, локална за възела, и живите сесии са отделни проблеми. Дръжте ги разделени, преди да репликирате един профил между възли.
Един профил, който може да влезе във всеки от два VPN възела, поставя въпрос за дизайна много преди въпрос за софтуера. Изгледът на профила, мрежата, която всеки възел притежава, и сесията, която държи свързан клиент, са три различни вида състояние и се провалят по различен начин, когато ги копирате насам-натам. Копирането и на трите в една система е често срещан начин да загубите едно от тях.
Минете през трите регистъра по-долу по ред. Всеки пита какво е авторитетно, какво е локално и какво се случва, когато другият възел го няма, а отговорите не следват един от друг.
Кой може да се свърже: един авторитет, много възли
Започнете с регистъра на достъпа: кой източник на идентичност е авторитетен, на кои издатели на сертификати се вярва, кои профили са допустими, кой втори фактор се прилага и до какво има достъп всеки профил. След това запишете как всеки възел научава за промените и колко бързо.
Споделената база данни е един възможен компонент на този отговор. Тя не е доказателство, че всяка свързана политика живее там или че всеки възел прилага промяна в един и същ момент. Профил, деактивиран на възел A, но все още приет на възел B, означава, че процесът на отписване не е завършен.
Решете какво прави възелът, когато авторитетът е недостъпен. Приемането на кеширани идентификационни данни по време на прекъсване е политически избор с цена за сигурността, а отхвърлянето им е политически избор с цена за наличността. И двете са защитими; оставянето им недокументирани не е.
Дръжте авторитета на издателя отделно от данните на профила. Няколко шлюза могат да се доверят на един и същ CA, без да държат неговия ключ за подписване, и всеки възел все още се нуждае от свой собствен сървърен сертификат и своя собствена доверителна връзка от страна на клиента.
Какво притежава възелът: адреси и маршрути
Вторият регистър е локален за всеки възел: адрес за слушане, идентичност на сървъра, пул от адреси, маршрути към частни ресурси, политика на резолвера и как трафикът излиза към интернет. Един и същ профил може да бъде обслужван от всеки от двата възела, докато тези обекти остават различни.
Обратният път е частта, която се забравя. Ако и двата възела раздават адреси от един и същ пул, частната мрежа не може да определи на кой възел принадлежи даден клиент и отговорът може да бъде изпратен на грешното място. Различните пулове също се нуждаят от маршрути и разрешения, така че отделен диапазон от номера не е пълен дизайн.
Насочвайте клиентите към възел съзнателно. Изборът на DNS, списъците с крайни точки на клиента и фронтенд услугата са различни механизми с различно поведение при здраве и при отказ. Изборът на един е добре; третирането на „балансиране на натоварването“ като дизайн оставя обратния път и поведението при отказ неопределени.
Документиран пример от продукт помага тук. Документацията на Pritunl за репликация разглежда VPN мрежата като обект за всяка реплика и клиентите на различни реплики се нуждаят от допълнителни маршрути и свързаност, за да се достигнат. Това е специфична за продукта подредба, а не рецепта за Community OpenVPN, но показва защо добавянето на реплика променя мрежата, а не само хранилището на профили.
Какво е сесията: живо състояние, а не ред
Третият регистър е живата сесия. Свързаният клиент има състояние на протокола и мрежово назначение на възела, който го е приел. Познаването на профила на другия възел не дава на този възел сесията, ключовете или способността да продължи пакетите.
Бъдете ясни какво се случва, когато възел се провали. Поддържаният резултат може да е повторно свързване към другия възел с ново удостоверяване и нов адрес, след което приложението се възстановява по свой начин. Ако е необходимо непрекъснато предаване, това изискване се нуждае от явна поддръжка в реализацията, а не от извод от репликацията на базата данни. Запишете отговора там, където дежурният инженер може да го намери.
Правилата за капацитет се нуждаят от същото третиране. Ограничение от две едновременни сесии на профил може да се наложи между възли само ако някакъв авторитет има координиран изглед на заетите места. Локалните за възлите списъци и историческият запис на профила не се събират в такъв изглед.
Изпитване на трите регистъра
Упражнете всеки поотделно. Влезте през възел A, после през възел B и потвърдете, че и двете успяват с очакваните диапазони от адреси. Оттеглете идентичност и проверете двата възела, а не само този, който случайно сте тествали. След това спрете един възел и наблюдавайте какво всъщност правят клиентът и частното приложение.
Включете обратния път в приемния тест. Клиент, който се свързва с B, но не може да получава отговори от ресурс зад A, е преминал проверката за достъп и е провалил мрежовата, и това разграничение трябва да се появи в доклада.
Дизайнът на профил за много възли е завършен само когато и трите регистъра имат явен собственик, път за промяна и поведение при отказ. Копирането на конфигурационен файл между възли не отговаря на нито един от тези въпроси.