Pse kopjimi i konfigurimit të serverit OpenVPN në një degë dështon

Kopjimi i konfigurimit funksional të serverit, zëvendësimi i disa adresave dhe quajtja e tij profil dege zakonisht prodhon një lidhje. Ky është rezultati më i keq, sepse dega më pas punon me rolin e gabuar, ekspozon material që nuk duhet të largohet nga hub-i dhe lë një shoqërim rruge që askush nuk mban mend ta ketë krijuar. Lidhja fsheh tre probleme njëherësh, dhe tuneli ngrihet para se dikush t'i kontrollojë ato.

Trajtimi i degës si një palë me identitet dhe rol rrjeti të vetin është ajo që e bën profilin të saktë. Rregullimi nuk është një kopje më e mirë, dhe pjesa tjetër e kësaj faqe flet për atë që një klient duhet të mbajë në të vërtetë.

Dy role që duken si një skedar

Në modalitetin TLS dy palët kanë detyra plotësuese. Njëra anë dëgjon, mban certifikatën dhe çelësin e serverit dhe vendos cilët klientë mund të lidhen. Ana tjetër fillon, verifikon dëgjuesin dhe paraqet identitetin e vet.

Një skedar serveri përmban direktiva që nuk kanë kuptim në një klient: një adresë lidhjeje dhe portë për të dëgjuar, një grup adresash për t'u shpërndarë dhe shpesh një listë shtytjeje për cilësimet që klientët duhet të marrin. Kopjimi i tyre në një degë prodhon një pajisje që përpiqet të jetë dëgjues dhe klient në të njëjtën kohë.

Çelësi privat është pjesa që ka më shumë rëndësi. Një klient nuk duhet të mbajë kurrë çelësin privat të serverit, dhe nuk ka nevojë as për çelësin e nënshkrimit të CA-së. Një certifikatë CA është material publik besimi; çelësi i nënshkrimit i përket vendit ku lëshohen certifikatat.

Çfarë duhet të përmbajë një profil dege

Një profil dege ka nevojë për pikën fundore të largët dhe transportin, identitetin e besuar të serverit, certifikatën dhe çelësin e vetë degës, si dhe rrugët dhe cilësimet DNS që dega kërkon vërtet. Asgjë tjetër nuk është e detyrueshme.

Mbajeni identitetin e degës të ndarë për secilin vendndodhje. Dy degë që ndajnë një certifikatë do të thotë që revokimi i njërës çaktivizon tjetrën, dhe regjistrat e hub-it nuk mund t'i dallojnë. Identiteti për vendndodhje është ai që bën të punojnë si gjurma e auditimit ashtu edhe historia e revokimit.

Kini kujdes me rrjedhat e punës të pajisjeve. Paketa Client Export e pfSense gjeneron profile për kontekstet e pranueshme Remote Access, dhe lista e serverëve të saj përfshin vetëm serverë të konfiguruar në një modalitet Remote Access. Një server vend-me-vend i një modaliteti tjetër nuk shfaqet, dhe kjo mungesë është informacion, jo ftesë për të kopjuar sekretet e serverit.

Nëse pajisja nuk eksporton profilin që ju nevojitet, përdorni rrjedhën e dokumentuar të punës së klientit vend-me-vend ose ndërtoni profilin nga shembulli i mbështetur i versionit të instaluar. Eksportoni një kopje rezervë të serverit në degë vetëm nëse plani është rivendosja e një serveri, gjë që nuk është. Kopja mbart edhe material privat të hub-it, prandaj zhvendosja e saj në një degë është vendim për trajtimin e çelësave, jo transferim skedari. Mbajeni në hub dhe gjeneroni identitetin e klientit atje ku lëshohen certifikatat.

Shoqërimi mes palës dhe rrjetit është i veçantë

Një klient dege që lidhet me sukses ende nuk mund të kalojë trafik për LAN-in e vet derisa hub-i të dijë se kjo palë zotëron atë parashtesë. Ky shoqërim jeton në hub, i lidhur me identitetin e klientit, dhe është i veçantë nga rruga e vetë degës drejt rrjeteve të largëta. Pa të, hostet e degës duken të arritshme në statistikat e tunelit dhe nuk janë të tilla në praktikë. Regjistri i hub-it është vendi ku konfirmohet nëse shoqërimi u aplikua.

Shtimi i një rruge në sistemin operativ të hub-it nuk është e njëjta gjë si t'i thuash OpenVPN-it cili klient zotëron parashtesën. Pa shoqërimin për çdo klient, paketa arrin ndërfaqen e tunelit dhe hidhet, sepse asnjë palë nuk pretendon destinacionin.

Në anën e degës, nevoja përkatëse është një rrugë drejt rrjeteve që duhet të arrijë, plus një router LAN që di të kthejë trafikun në degë. Zotërimi në anën e serverit dhe rrugët e destinacionit në anën e klientit janë objekte të ndryshme, dhe një tunel që punon provon vetëm kërcimin e parë. Shkruajini të dyja në shënimet e dorëzimit të degës, sepse inxhinieri i ardhshëm do të gjejë vetëm njërën prej tyre.

Të provosh se dega është pala që mendoni

Verifikoni identitetin para se të verifikoni trafikun. Regjistri i hub-it duhet të tregojë emrin e përbashkët të certifikatës së degës, dhe adresa që klienti mori duhet të përputhet me grupin ose caktimin fiks që keni dashur. Nëse regjistri tregon një emër tjetër, profili mbart identitetin e dikujt tjetër.

Më pas verifikoni shoqërimin duke dërguar një kërkesë nga një host i degës drejt një burimi në anën e hub-it dhe konfirmoni që ajo ka sukses me adresën e pritur të burimit. Testoni një destinacion që dega nuk duhet të arrijë dhe konfirmoni që dështon, sepse një rrugë lejuese që punon rastësisht nuk është e njëjtë me një politikë të saktë.

Së fundi, revokoni identitetin e degës dhe konfirmoni që lidhja dështon ndërsa certifikata e hub-it vetë dhe vendndodhjet e tjera vazhdojnë të punojnë. Nëse revokimi e prish hub-in, rolet dhe identitetet u ndanë diku, dhe ky është gjetja që ia vlen të kthehet në projektim.

Një degë e përfunduar është ajo me identitet të dokumentuar, profil vetëm për klient, shoqërim mes palës dhe rrjetit në hub dhe një rrugë kthimi të provuar. Kthimi i tekstit në një skedar serveri nuk ju jep asnjërën prej tyre.