A mundet kjo shtojcë e NetworkManager të ekzekutojë dy VPN njëkohësisht?

Në listën e lidhjeve qëndrojnë dy zëra VPN, të dy thonë të lidhur, dhe vetëm njëri prej tyre mbart trafikun që prisnit. Ose i dyti refuzon plotësisht të nisë, dhe askush nuk mund të thotë nëse faji është te shtojca, te klienti apo te një politikë që e harruat. Pretendimet për një kufi prej një VPN përshkruajnë zbatime të caktuara, dhe zbatimet ndryshojnë. Kaloni fillimisht aftësinë, pastaj koordinimin.

Numëroni profilet e ruajtura, pastaj aktivizimet

Një profil i ruajtur është objekt konfigurimi, dhe një lidhje aktive është një instancë në punë. Lista i shkrin vizualisht të dy konceptet, prandaj të dy raportet tingëllojnë të vërteta. Filloni duke emërtuar objektet e sakta me UUID-t e tyre, sepse emri i shfaqur nuk është unik dhe një import i vjetër shpesh ndan etiketën me një zë më të ri. Pastaj kontrolloni veçmas listën e aktiveve dhe shihni cilat UUID shfaqen. Vetëm atëherë e dini nëse po krahasoni dy konfigurime apo dy tunele të gjalla.

Aktivizimi i të njëjtit UUID dy herë është një rast i tretë, dhe nuk është njëkohësi. Është riaktivizim i një instance të vetme.

Lexoni metadatat e vetë shtojcës

Çdo shtojcë VPN vjen me një skedar të vogël metadatash që menaxheri lexon, dhe ato skedarë mund të deklarojnë nëse shtojca mbështet disa lidhje njëkohësisht. Lexoni skedarin e instaluar në këtë makinë në vend që të përsërisni atë që shkruan aktualisht një projekt upstream, sepse paketa e shpërndarjes vendos çfarë keni në të vërtetë. I njëjti kontroll vlen për çdo protokoll: një përgjigje për një shtojcë nuk thotë asgjë për një tjetër. Shënoni versionin e paketës pranë rezultatit, që një krahasim i mëvonshëm të ketë kuptim.

Këshillat e vjetra për një kufi prej një VPN përshkruanin integtime më të vjetra. Nuk është as gjithmonë e vërtetë as e sigurt ta marrësh si fikse, dhe skedari përpara jush e zgjidh atë në vend.

Njëkohës nuk do të thotë i koordinuar

Fakti që dy shtojca nisin me sukses provon aftësinë, jo dizajnin. Dy tunele që të dy ofrojnë një rrugë të paracaktuar do të konkurrojnë, dhe ai që e instaloi rrugën e vet i fundit zakonisht fiton pa e shpallur. Gama private që mbivendosen kanë të njëjtin problem në formë më të vogël.

Vendosni cilat destinacione i përkasin cilit profil përpara se të aktivizoni gjithçka. Riemërtimi i një profili nuk i dallon destinacionet.

DNS zgjedh një fitues, pavarësisht nga fakti nëse ju e bëni apo jo

Cilësimet e zgjidhësit janë për çdo profil, dhe kur dy janë aktivë, rendi i zgjidhjes vendoset nga politika dhe prioriteti, jo nga qëllimi. Profili që u ngrit i fundit mund të zotërojë në heshtje çdo emër korporativ.

Caktoini çdo hapësire emrash private zgjidhësit që duhet të përgjigjet për të, dhe vendosni preferencën e rrugëzimit me qëllim në vend që të mbështeteni te rendi. Pastaj provoni një emër nga çdo hapësirë me të dy tunelet lart, dhe përsëri me njërin prej tyre të shkëputur. Një zgjidhës që punon vetëm sa kohë që të dy tunelet janë lart është një dizajn që do të befasojë dikë në momentin më të keq të mundshëm.

Vendosni në një rend fiks dhe inspektoni në mes

Aktivizoni një profil, inspektoni gjendjen e rrugëve dhe të zgjidhësit të tij, pastaj aktivizoni të dytin dhe inspektoni përsëri. Krahasimi i dy gjendjeve ju tregon çfarë ndryshoi dhe cili profil zotëron çfarë. Mos i aktivizoni të dy dhe pastaj diagnozoni rezultatin.

Provoni çdo burim të nevojshëm përmes tunelit që duhet ta mbartë, pastaj shkëputni një profil dhe konfirmoni që tjetri mban rrugët e tij, DNS-në e tij dhe sjelljen e synuar të dështimit. Nëse shtojca e vendosur vërtet nuk mund të bëjë atë që ju nevojitet, zgjidhni një përditësim të mbështetur ose një alternativë të izoluar shprehimisht në vend që të ringjallni një protokoll të vjetruar pranë menaxherit. Një tunel i dytë, i veçantë që askush nuk e administron nuk është izolim; është një burim tjetër rrugësh befasuese.