Unu OpenVPN-centro, tri LAN-oj: adresa plano kaj iroute-dosieroj

Tri privataj LAN-oj povas renkontiĝi ĉe unu centro sen ke iu ajn retejo ekkonu la internaĵojn de la aliaj, kaj la tuta dezajno ripozas sur kvar mallongaj agordaj decidoj. Kio igas ĝin funkcii ne estas ekzota protokola trajto, sed adresa plano kiun neniu devas diveni, plus itineroj po kliento kiuj diras al la centro kiu branĉo posedas kiun prefikson. Eraru pri iu ajn el tiuj kaj la tunelo tamen leviĝas, kaj ĝuste tio igas la fiaskon konfuza.

Trairu la paŝojn laŭ ordo. Ĉiu dependas de la plano el la antaŭa paŝo, kaj neniu postulas novan atestan aŭtoritaton.

Komencu per plano kiun neniu devas diveni

Notu kvar disajn prefiksojn antaŭ ol tuŝi agordan dosieron: la propran LAN-on de la centro, la LAN-on de ĉiu branĉo, kaj la naĝejon donitan al migrantaj klientoj. Diseco estas tio kio tenas ĉion alian simpla, ĉar koincidaj intervaloj transformas itinadon en enigmon de plej longa kongruo kiun neniu agordo po kliento riparas. Poste konfirmu kiun maŝinon estas la implicita enirejo por ĉiu LAN, ĉar branĉa itinilo kiu ne estas la enirejo de sia LAN bezonas la malproksimajn itinerojn instalitaj tute aliloke. Fine, fiksu la aŭtentikigitajn nomojn kiuj identigas ĉiun branĉon, ĉar tiuj nomoj estas la ŝlosiloj per kiuj oni serĉas la dosierojn po kliento.

Ilustra plano tenas la naĝejon sufiĉe for de la tri LAN-oj. La via estos malsama, kaj la sola malmola regulo estas ke neniuj du intervaloj koincidu.

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/24

Diru al la kerno de la centro kie estas la branĉoj

La centro bezonas du informerojn po branĉo: kernan itineron kiu sendas la prefikson en la tunelan aparaton, kaj iroute enskribon kiu diras al la OpenVPN procezo kiun klienton posedas ĝin. La kerna itinero sole liveras pakaĵojn al la tunelo kaj haltas tie, ĉar la demono ankoraŭ devas decidi kiun samtavolanon ricevu ilin. La iroute enskribo sole lasas tiujn pakaĵojn en la kerno sen itinero por sekvi. Ambaŭ linioj apartenas al la agordo kiun la demono efektive ŝargas, kio indas kontroli antaŭ ol sencimigi ion ajn alian.

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.0

Malŝaltu klient-al-klient kiam la kerno devas esti la plenumiga punkto. Tiu opcio plusendas samtavolan trafikon ene de la demono, kio estas oportuna kaj ankaŭ signifas ke viaj plusendaj reguloj neniam vidas la fluon. Ĉio sube supozas ke la kerno vidas ĉiun pakaĵon inter branĉoj.

Donu al ĉiu branĉo la itinerojn kiujn ĝi bezonas

Ĉiu branĉo bezonas itinerojn al la aliaj branĉoj kaj al la LAN de la centro, kaj ĝi ne bezonas unu por sia propra konektita LAN. Puŝu la malproksimajn prefiksojn el la centro anstataŭ englui ilin en ĉiun itinilon, tiel ke kvara retejo poste signifas unu novan dosieron po kliento anstataŭ kvar redaktoj. La dosiero po kliento ankaŭ portas la linion iroute, kiu tenas posedon kaj anoncon en la sama loko. Faru la dosierujon kaj ĝiajn dosierojn legeblaj laŭ la privilegia modelo de la servilo, alie la serĉo fiaskas sen mesaĝo.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Kvara retejo sekvas la saman ŝablonon: aparta aŭtentikigita nomo, posedata prefikso, kerna itinero de la centro, iroute enskribo, kaj anoncoj nur al la retejoj rajtigitaj atingi ĝin.

Testu en ambaŭ direktoj antaŭ ol deklari ĝin finita

Ŝaltu IPv4-plusendadon sur ĉiuj tri itiniloj, poste konfirmu ke la fajroŝirmilo permesas la celatajn fluojn en ambaŭ direktoj, ĉar unudirekta testo sukcesas kun rompita revena vojo pli ofte ol iu ajn atendas. Inter retejoj ne necesas fonta tradukado, kaj ĝuste konservado de la originala fonto ebligas al ĉiu branĉo apliki sian propran politikon al peto.

Testu de gastiganto en la LAN de unu branĉo al servo en alia, poste inversigu la direkton, poste testu de branĉo al la LAN de la centro. Tiuj tri rezultoj estas malsamaj pruvoj, kaj neniu el ili implicas la aliajn. Se branĉa itinilo ne estas la implicita enirejo de sia LAN, instalu la malproksimajn prefiksojn sur la reala enirejo kaj inkluzivi ankaŭ la naĝejon kiam tunelaj klientoj devas komenci konektojn en tiun LAN-on.

Registru la planon, la dosierojn po kliento kaj la fajroŝirmilajn regulojn kiel unu dokumenton, ĉar la sekva aldono de retejo estos juĝata laŭ ili.

La dezajno teniĝas kune ĉar ĉiu tavolo havas unu taskon: la plano tenas prefiksojn unikaj, la kerna itinero movas pakaĵojn, la iroute nomas la posedanton, kaj la fajroŝirmilo decidas kio estas permesita. Kiam io rompiĝas, tiu listo estas ankaŭ la ordo en kiu kontroli ĝin.