Një hub OpenVPN, tre rrjeta LAN: plani i adresave dhe skedarët iroute
Katër prefikse të veçuara, një rrugë kernel për degë, një iroute për pronar. Një rend pune për një hub me tre vende që dështon në heshtje kur një emër është i gabuar.
Tre rrjeta LAN private mund të takohen në një hub të vetëm pa pasur nevojë që asnjë vend të njohë strukturën e brendshme të të tjerëve, dhe i gjithë projekti qëndron mbi katër vendime të shkurtra konfigurimi. Atë që e bën të funksionojë nuk është një veçori ekzotike protokolli, por një plan adresash që askush nuk duhet ta hamendësojë, plus rrugë për çdo klient që i thonë hub-it cila degë zotëron cilin prefiks. Nëse njëra prej tyre është e gabuar, tuneli prapë ngrihet, dhe pikërisht kjo e bën dështimin konfuz.
Ndiqu hapat me radhë. Secili varet nga plani i hapit paraardhës, dhe asnjë nuk kërkon një autoritet të ri certifikimi.
Filloni me një plan që askush nuk duhet ta hamendësojë
Shkruani katër prefikse të veçuara përpara se të prekni një skedar konfigurimi: LAN-in e vetë hub-it, LAN-in e secilës degë dhe grupin që u jepet klientëve endacakë. Veçimi është ai që mban gjithçka tjetër të thjeshtë, sepse intervalet që mbivendosen e kthejnë rrugëzimin në një enigmë të përputhjes më të gjatë që asnjë konfigurim për klient nuk e rregullon. Më pas konfirmoni cila makinë është porta standarde për çdo LAN, pasi një ruter dege që nuk është porta e LAN-it të vet duhet t'i instalojë rrugët e largëta diku tjetër krejt. Së fundi, caktoni emrat e autentikuar që identifikojnë secilën degë, sepse ata emra janë çelësat me të cilët kërkohen skedarët për klient.
Një plan ilustrues e mban grupin larg tre rrjeteve LAN. I juaji do të jetë i ndryshëm, dhe rregulli i vetëm i fortë është që asnjë dy intervale të mos mbivendosen.
Hub LAN 172.20.0.0/24
Branch A LAN 172.21.0.0/24
Branch B LAN 172.22.0.0/24
VPN pool 10.77.0.0/24
identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24Tregojini kernelit të hub-it ku janë degët
Hub-i ka nevojë për dy informacione për secilën degë: një rrugë kernel që e dërgon prefiksin në pajisjen e tunelit dhe një zë iroute që i thotë procesit OpenVPN cili klient e zotëron. Vetëm rruga kernel i dorëzon paketat në tunel dhe ndalon aty, sepse daemoni ende duhet të vendosë cili peer duhet t'i marrë. Vetëm zëri iroute i lë ato paketa në kernel pa asnjë rrugë për t'u ndjekur. Të dy rreshtat i përkasin konfigurimit që daemoni ngarkon vërtet, dhe ia vlen ta verifikosh përpara se të korrigjosh çdo gjë tjetër.
dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco
route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0Mbaje client-to-client të fikur kur kernel-i duhet të jetë pika e zbatimit të rregullave. Ai opsion e përcjell trafikun mes peer-ëve brenda daemonit, gjë që është e përshtatshme dhe gjithashtu do të thotë që rregullat e tua të përcjelljes nuk e shohin kurrë rrjedhën. Gjithçka më poshtë supozon se kernel-i sheh çdo paketë mes degëve.
Jepi secilës degë rrugët që i nevojiten
Secila degë ka nevojë për rrugë drejt degëve të tjera dhe drejt LAN-it të hub-it, dhe nuk ka nevojë për një drejt LAN-it të vet të lidhur. Shtyjini prefikset e largëta nga hub-i në vend që t'i ngjitni në çdo ruter, kështu që një vend i katërt më vonë do të thotë një skedar i ri për klient në vend të katër ndryshimeve. Skedari për klient mbart gjithashtu rreshtin iroute, që e mban pronësinë dhe shpalljen në të njëjtin vend. Bëji drejtorinë dhe skedarët e saj të lexueshëm sipas modelit të privilegjeve të serverit, përndryshe kërkimi dështon pa mesazh.
# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"Një vend i katërt ndjek të njëjtin model: një emër i veçantë i autentikuar, një prefiks i zotëruar, një rrugë kernel në hub, një zë iroute dhe shpallje vetëm për vendet që lejohen ta arrijnë.
Testo në të dyja drejtimet përpara se ta shpallësh të përfunduar
Aktivizo përcjelljen IPv4 në të tre ruterat, më pas konfirmo që firewalli i lejon rrjedhat e synuara në të dyja drejtimet, sepse një test njëdrejtimësh kalon me një rrugë kthimi të thyer më shpesh sesa pritet. Mes vendeve nuk nevojitet përkthim i adresës burimore, dhe ruajtja e burimit origjinal është pikërisht ajo që i lejon secilës degë të zbatojë politikën e vet mbi një kërkesë.
Testo nga një host në një LAN dege drejt një shërbimi në një tjetër, pastaj ktheje drejtimin, pastaj testo nga një degë drejt LAN-it të hub-it. Ato tre rezultate janë prova të ndryshme, dhe asnjëri nuk i nënkupton të tjerët. Nëse ruteri i degës nuk është porta standarde e LAN-it të vet, instaloni prefikset e largëta në portën e vërtetë dhe përfshini edhe grupin kur klientët e tunelit duhet të nisin lidhje në atë LAN.
Regjistro planin, skedarët për klient dhe rregullat e firewall-it si një dokument të vetëm, sepse shtimi i vendit të ardhshëm do të gjykohet sipas tyre.
Projekti mbahet bashkë sepse çdo shtresë ka një detyrë: plani i mban prefikset unikë, rruga kernel i lëviz paketat, iroute emërton pronarin dhe firewalli vendos çfarë lejohet. Kur diçka prishet, ai listë është edhe rendi i kontrollit.