Један VPN налог на два сервера: три регистра стања
Заједничко прихватање, мрежна конфигурација локална за чвор и живе сесије су одвојени проблеми. Држите их одвојено пре него што реплицирате један налог између чворова.
Један налог који може да се пријави на било који од два VPN чвора поставља пројектно питање много пре него што постави питање софтвера. Поглед на налог, мрежа коју поседује сваки чвор и сесија коју држи повезан клијент три су различите врсте стања, и отказују на различите начине када их копирате около. Копирање сва три у један систем чест је начин да изгубите један од њих.
Прођите кроз три регистра испод по реду. Сваки пита шта је ауторитативно, шта је локално и шта се дешава када другог чвора нема, а одговори не следе један из другог.
Ко може да се повеже: један ауторитет, много чворова
Почните од регистра прихватања: који извор идентитета је ауторитативан, којим издаваоцима сертификата се верује, који налози испуњавају услове, који други фактор се примењује и до чега сваки налог може да дође. Затим запишите како сваки чвор сазнаје за промене и колико брзо.
Заједничка база података један је могући део тог одговора. Она није доказ да свака релевантна политика живи тамо или да сваки чвор примењује промену у истом тренутку. Налог онемогућен на чвору A, али још прихваћен на чвору B, значи да процес одјаве није завршен.
Одлучите шта чвор ради када је ауторитет недоступан. Прихватање кешираних акредитива током испада је политички избор са ценом за безбедност, а њихово одбијање је политички избор са ценом за доступност. Оба се могу бранити; оставити то недокументовано не може.
Држите ауторитет издаваоца одвојено од података налога. Неколико пролаза може веровати истом CA без држања његовог кључа за потписивање, а сваком чвору и даље треба сопствени серверски сертификат и сопствени однос поверења на страни клијента.
Шта чвор поседује: адресе и путање
Други регистар је локалан за сваки чвор: адреса слушања, идентитет сервера, скуп адреса, путање до приватних ресурса, политика разрешивача и како саобраћај излази ка интернету. Исти налог може да опслужује било који чвор, док ти објекти остају различити.
Повратна путања је део који се заборавља. Ако оба чвора деле адресе из истог скупа, приватна мрежа не може да каже ком чвору припада дати клијент, а одговор може да оде на погрешно место. Различити скупови такође траже путање и дозволе, па посебан опсег бројева није потпун пројекат.
Усмерите клијенте на чвор намерно. Избор DNS-а, листе крајњих тачака клијента и фронтенд услуга различити су механизми са различитим понашањем здравља и пребацивања при отказу. Изабрати један је у реду; третирати „балансирање оптерећења“ као пројекат оставља повратну путању и понашање при отказу недефинисаним.
Документован пример производа помаже овде. Pritunl документација о репликацији третира VPN мрежу као објекат по реплици, а клијенти на различитим репликама требају додатне путање и повезаност да би стигли једни друге. То је распоред специфичан за производ, не рецепт за Community OpenVPN, али показује зашто додавање реплике мења мрежу, а не само складиште налога.
Шта је сесија: живо стање, а не ред
Трећи регистар је жива сесија. Повезани клијент има стање протокола и мрежну доделу на чвору који га је прихватио. То што је налог познат на другом чвору не даје том чвору сесију, кључеве или могућност да настави пакете.
Будите изричити о томе шта се дешава када чвор откаже. Подржани исход може бити поновно повезивање на други чвор са свежом аутентификацијом и новом адресом, након чега се апликација опоравља на свој начин. Ако је потребно непрекидно предавање, тај захтев тражи изричиту подршку у имплементацији, а не закључак из репликације базе података. Запишите одговор тамо где инжењер у дежурству може да га нађе.
Правила капацитета траже исти третман. Ограничење од две истовремене сесије по налогу може се спровести између чворова само ако неки ауторитет има координисан поглед на заузета места. Листе локалне за чворове и историјски запис налога не сабирају се у такав поглед.
Испробавање три регистра
Вежбајте сваки засебно. Пријавите се преко чвора A, затим преко чвора B и потврдите да оба успевају са очекиваним опсезима адреса. Повуците идентитет и проверите оба чвора, не само онај који сте случајно тестирали. Затим зауставите један чвор и посматрајте шта клијент и приватна апликација заиста раде.
Укључите повратну путању у пријемни тест. Клијент који се повеже на B, али не може да прима одговоре од ресурса иза A, прошао је проверу прихватања и пао на мрежној, и та разлика треба да се појави у извештају.
Пројекат налога за више чворова потпун је само када сва три регистра имају изричитог власника, путању промене и понашање при отказу. Копирање конфигурационе датотеке између чворова не одговара ни на једно од тих питања.