Kopjoni profilin në tablet, lidhuni, dhe laptopi bie. Shtoni duplicate-cn, të dyja mbeten të lidhura, dhe problemi duket i zgjidhur derisa dy pajisjet të grinden për të njëjtën adresë tuneli ose një tablet i humbur e nxjerr të gjithë llogarinë jashtë linje. Opsioni ndryshon një gjë dhe vetëm një: nëse serveri lejon një sesion të dytë nën një emër që e ka parë tashmë. Gjithçka që njerëzit presin të rregullojë, nga pavarësia e pajisjeve te adresimi për çdo pajisje dhe revokimi selektiv, vazhdon të bëhet me identitet, dhe identiteti këtu është certifikata.

Miti: një sesion i dytë është një identitet i dytë

Intuita thotë se dy lidhje duhet të jenë dy klientë, dhe dy klientë duhet të jenë dy pajisje me të drejtat e tyre. Serveri nuk e modelon kështu. Ai sheh një emër të përbashkët dhe, me duplicate-cn të aktivizuar, pranon më shumë se një sesion aktiv që mban atë emër, dhe secili merr gjendjen e vet të sesionit në daemon.

Asgjë në atë pranim nuk prek verifikimin e certifikatës. E njëjta certifikatë mbetet kredenciali, i njëjti kyç mbetet kyçi privat, dhe çdo politikë e bazuar në subjektin e certifikatës zgjidhet ende dy herë në të njëjtën vlerë. Një sesion i dytë është një socket i dytë, jo një identitet i dytë.

Ky dallim është i padukshëm sa kohë që gjithçka funksionon. Bëhet shumë i dukshëm në momentin kur duhet t'i dalloni dy pajisjet, dhe zakonisht është dita kur njëra prej tyre humbet.

Çfarë ndryshon vërtet kur dy sesione ndajnë një emër

Pa opsionin, një lidhje e re nën një emër të përbashkët që është tashmë i lidhur e zhvendos sesionin e mëparshëm. Kjo është arsyeja pse laptopi bie kur lidhet tableti, dhe është një mbrojtje e qëllimshme kundër paqartësisë, jo një defekt. Me opsionin, të dy sesionet mbeten gjallë dhe serveri i ndjek veçmas sipas sesionit, jo sipas pajisjes.

Secili sesion merr ende lidhjen e vet të jashtme dhe kyçet e veta të negociuara, kështu që xhiroja e njëkohshme është vërtet e njëkohshme. Ajo që ndajnë është gjithçka që rrjedh nga kredenciali: kërkimet e politikave, konfigurimi specifik për klientin, identiteti në regjistra dhe revokimi. Gjendja e sesionit i përket lidhjes dhe vdes me të, ndërsa faktet në nivel kredenciali mbeten për të dyja. Kjo është arsyeja pse dalja e statusit mund të listojë të njëjtin emër dy herë ndërsa numëruesit mbeten të ndarë.

Verifikoni çfarë bën në të vërtetë ndërtimi juaj përpara se të projektoni mbi të, sepse efekti i opsionit përcaktohet nga vetë opsioni dhe jo nga thashethemet:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

Adresa statike që menduat se e kishit caktuar

Konfigurimi për çdo klient kërkohet sipas emrit, dhe aty është kurthi. Një skedar client-config-dir i emërtuar sipas emrit të përbashkët zbatohet për çdo pajisje që përdor atë emër, kështu që një ifconfig-push brenda tij u jep të dy pajisjeve të njëjtën adresë tuneli. Sesioni i dytë ose nuk vendoset, ose përplaset në një mënyrë që duket si defekt rrugëtimi.

Një pishinë dinamike sillet më mirë rastësisht, sepse secilit sesion i caktohet në mënyrë të pavarur një adresë nga pishina. Kjo ende nuk ju jep një adresë të qëndrueshme për çdo pajisje, dhe sigurisht nuk ju jep një politikë për çdo pajisje të lidhur me atë adresë.

Nëse vendosja përdor username-as-common-name, kyçi i kërkimit bëhet emri i përdoruesit i vërtetuar në vend të subjektit të certifikatës, dhe i njëjti përplasje ndjek këdo që hyn dy herë. Emri që drejton konfigurimin duhet të jetë unik për çdo pajisje që konfigurimi për çdo pajisje të ketë kuptim.

Çfarë nuk mund të bëjë një identitet i përbashkët në momentin e heqjes

Revokimi vepron mbi certifikatën, jo mbi emrin e shfaqur dhe jo mbi sesionin. Revokoni atë certifikatë dhe çdo pajisje që mban një kopje humbet aksesin menjëherë, përfshirë atë në zyrë që askush nuk dëshiron ta shqetësojë. Mbani atë dhe pajisja e humbur vazhdon të funksionojë, sepse asgjë në protokoll nuk e dallon nga kopja e miratuar.

Regjistrat trashëgojnë të njëjtën paqartësi. Dalja e statusit tregon një emër të përbashkët dhe një adresë reale, dhe të dyja mund t'i përkasin secilës prej dy pajisjeve. Një rishikim incidenti që duhet të dijë cila makinë bëri çfarë nuk mund t'i përgjigjet kësaj pyetjeje nga të dhënat e vetë VPN-së, sado hollësi të japë niveli i regjistrit.

Nuk ka zgjidhje kriptografike për këtë. Dy pajisje që paraqesin të njëjtën certifikatë janë, për serverin, i njëjti pjesëmarrës dy herë, dhe çdo skemë që pretendon të kundërtën është konventë emërtimi dhe jo kontroll.

Kur ndarja është e drejtë dhe si ta kufizoni atë

Ndarja ka përdorime legjitime: një llogari laboratori e përdorur nga disa makina testimi, ose një familje ku pajisjet administrohen së bashku dhe hollësia e revokimit nuk ka rëndësi. Në ato raste, aktivizoni opsionin me qëllim, mbani kredencialin e përbashkët jashtë politikës për çdo pajisje, dhe jepini pishinës hapësirë që sesionet të mos përplasen në një adresë.

Për gjithçka që kërkon adresa të veçanta, regjistra të veçantë ose heqje të veçantë, lëshoni certifikata të veçanta përmes rrugës normale të regjistrimit. Kjo i jep çdo sistemi në rrjedhën e poshtme një objekt të veçantë ku të mbështetet, dhe opsioni pushon së qeni i rëndësishëm sepse emrat janë tashmë unikë.

Cilën rrugë të zgjidhni, provoni modelin e menaxhimit dhe jo hyrjen. Lidhni të dyja pajisjet, konfirmoni që kanë adresa të ndryshme, pastaj simuloni një humbje dhe kontrolloni që mund të hiqni saktësisht njërën prej tyre. Manuali openvpn(8) përcakton shtrirjen e opsionit; procedura juaj e heqjes përcakton nëse ndarja është vërtet e pranueshme.

Artikuj të ngjashëm