Viens VPN konts divos serveros: trīs stāvokļa reģistri

Viens konts, kas var pierakstīties jebkurā no diviem VPN mezgliem, izvirza dizaina jautājumu krietni pirms programmatūras jautājuma. Konta skats, katra mezgla pārvaldītais tīkls un pieslēgta klienta turētā sesija ir trīs dažādi stāvokļa veidi, un tie sabrūk dažādi, kad tos kopējat šurpu turpu. Visu trīs kopēšana vienā sistēmā ir ierasts veids, kā zaudēt vienu no tiem.

Izskatiet trīs zemāk esošos reģistrus pēc kārtas. Katrs jautā, kas ir pilnvarots, kas ir lokāls un kas notiek, kad otrs mezgls nav pieejams, un atbildes viena no otras neizriet.

Kas drīkst pievienoties: viena autoritāte, daudzi mezgli

Sāciet ar uzņemšanas reģistru: kurš identitātes avots ir pilnvarots, kuriem sertifikātu izdevējiem uzticas, kuri konti ir atbilstoši, kurš otrais faktors tiek piemērots un ko katrs konts var sasniegt. Pēc tam pierakstiet, kā katrs mezgls uzzina par izmaiņām un cik ātri.

Kopīga datu bāze ir viena iespējama šīs atbildes sastāvdaļa. Tā nav pierādījums, ka tur dzīvo katra attiecīgā politika vai ka katrs mezgls izmaiņas piemēro tajā pašā mirklī. Konts, kas atspējots mezglā A, bet joprojām pieņemts mezglā B, nozīmē, ka iziešanas process nav pabeigts.

Izlemiet, ko mezgls dara, kad autoritāte nav sasniedzama. Kešoto akreditācijas datu pieņemšana pārtraukuma laikā ir politikas izvēle ar drošības izmaksām, un to noraidīšana ir politikas izvēle ar pieejamības izmaksām. Abas ir aizstāvamas; atstāt to nedokumentētu nav.

Turiet izdevēja autoritāti atsevišķi no konta datiem. Vairāki vārteji var uzticēties vienam un tam pašam CA, neturot tā parakstīšanas atslēgu, un katram mezglam joprojām vajag savu servera sertifikātu un savas klienta puses uzticēšanās attiecības.

Kas pieder mezglam: adreses un maršruti

Otrais reģistrs ir lokāls katram mezglam: klausīšanās adrese, servera identitāte, adrešu pūls, maršruti uz privātiem resursiem, atrisinātāja politika un kā trafiks iziet uz internetu. Vienu un to pašu kontu var apkalpot jebkurš mezgls, kamēr šie objekti paliek atšķirīgi.

Atgriešanās ceļš ir tā daļa, kas tiek aizmirsta. Ja abi mezgli izdala adreses no viena pūla, privātais tīkls nevar pateikt, kuram mezglam pieder konkrēts klients, un atbilde var aiziet nepareizajā vietā. Dažādiem pūliem arī vajag maršrutus un atļaujas, tāpēc atsevišķs numuru diapazons nav pilnīgs dizains.

Novirziet klientus uz mezglu apzināti. DNS izvēle, klienta galapunktu saraksti un priekšgala pakalpojums ir dažādi mehānismi ar atšķirīgu veselības un pārslēgšanās uzvedību. Izvēlēties vienu ir labi; uzskatīt „slodzes balansēšanu“ par dizainu atstāj atgriešanās ceļu un kļūmes uzvedību nedefinētu.

Dokumentēts produkta piemērs šeit palīdz. Pritunl replikācijas dokumentācija VPN tīklu uzskata par objektu katrai replikai, un klientiem dažādās replikās vajag papildu maršrutus un savienojamību, lai sasniegtu viens otru. Tas ir produktam raksturīgs izkārtojums, nevis Community OpenVPN recepte, bet tas parāda, kāpēc replikas pievienošana maina tīklu, ne tikai kontu krātuvi.

Kas ir sesija: dzīvs stāvoklis, ne rinda

Trešais reģistrs ir aktīvā sesija. Pieslēgtam klientam ir protokola stāvoklis un tīkla piešķīrums mezglā, kas to pieņēma. Tas, ka konts ir zināms otrā mezglā, tam mezglam nedod ne sesiju, ne atslēgas, ne spēju turpināt paketes.

Esiet skaidri par to, kas notiek, kad mezgls sabrūk. Atbalstītais iznākums var būt atkārtota pievienošanās otram mezglam ar svaigu autentifikāciju un jaunu adresi, pēc kā lietotne atjaunojas savā veidā. Ja nepieciešama nepārtraukta nodošana, šī prasība prasa skaidru ieviešanas atbalstu, nevis secinājumu no datu bāzes replikācijas. Pierakstiet atbildi tur, kur dežurējošais inženieris to atradīs.

Kapacitātes noteikumiem vajag tādu pašu attieksmi. Divu vienlaicīgu sesiju ierobežojumu vienam kontam var piemērot starp mezgliem tikai tad, ja kādai autoritātei ir saskaņots skats uz aizņemtajām vietām. Mezglam lokāli saraksti un vēsturisks konta ieraksts šādā skatā nesasummējas.

Trīs reģistru pārbaude

Praktizējiet katru atsevišķi. Piesakieties caur mezglu A, pēc tam caur mezglu B, un apstipriniet, ka abi izdodas ar gaidītajiem adrešu diapazoniem. Atsauciet identitāti un pārbaudiet abus mezglus, ne tikai to, kuru nejauši pārbaudījāt. Pēc tam apturiet vienu mezglu un vērojiet, ko klienta un privātā lietotne faktiski dara.

Iekļaujiet atgriešanās ceļu pieņemšanas testā. Klients, kas pieslēdzas B, bet nevar saņemt atbildes no resursa aiz A, ir izturējis uzņemšanas pārbaudi un izkritis tīkla pārbaudē, un šai atšķirībai jāparādās ziņojumā.

Daudzmezglu konta dizains ir pilnīgs tikai tad, kad visiem trim reģistriem ir skaidrs īpašnieks, izmaiņu ceļš un kļūmes uzvedība. Konfigurācijas faila kopēšana starp mezgliem neatbild ne uz vienu no šiem jautājumiem.