Isang hub ng OpenVPN, tatlong LAN: plano ng address at mga file ng iroute

Tatlong pribadong LAN ang maaaring magtagpo sa isang hub nang hindi kailangang malaman ng alinmang site ang panloob na istruktura ng iba, at ang buong disenyo ay nakasalalay sa apat na maiikling desisyon sa konfigurasyon. Ang nagpapagana nito ay hindi isang kakaibang tampok ng protocol, kundi isang plano ng address na hindi kailangang hulaan ninuman, kasama ang mga ruta bawat kliyente na nagsasabi sa hub kung aling sangay ang may-ari ng aling prefix. Kung mali ang isa sa dalawa, umaangat pa rin ang tunnel, at iyon mismo ang nagpapagulo sa pagkabigo.

Sundin ang mga hakbang sa pagkakasunod-sunod. Ang bawat hakbang ay nakadepende sa plano ng naunang hakbang, at wala sa kanila ang nangangailangan ng bagong awtoridad ng sertipiko.

Magsimula sa planong hindi kailangang hulaan ninuman

Isulat ang apat na magkakahiwalay na prefix bago hawakan ang isang file ng konfigurasyon: ang LAN ng hub mismo, ang LAN ng bawat sangay, at ang pool na ibinibigay sa mga gumagalang kliyente. Ang pagiging magkakahiwalay ang nagpapanatiling simple ng lahat ng iba pa, dahil ang magkakapatong na saklaw ay ginagawang palaisipan ng pinakamahabang tugma ang pagruruta na hindi kayang ayusin ng anumang konfigurasyon bawat kliyente. Pagkatapos, kumpirmahin kung aling makina ang default na gateway ng bawat LAN, dahil ang router ng sangay na hindi gateway ng sarili nitong LAN ay kailangang mag-install ng malalayong ruta sa ibang lugar nang lubusan. Sa huli, itakda ang mga awtentikadong pangalan na kumikilala sa bawat sangay, dahil ang mga pangalang iyon ang mga susi kung saan hinahanap ang mga file bawat kliyente.

Ang isang halimbawang plano ay naglalayo sa pool mula sa tatlong LAN. Magiging iba ang sa iyo, at ang tanging matigas na tuntunin ay walang dalawang saklaw na magkapatong.

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

Sabihin sa kernel ng hub kung nasaan ang mga sangay

Ang hub ay nangangailangan ng dalawang impormasyon bawat sangay: isang kernel route na nagpapadala ng prefix sa aparato ng tunnel, at isang entry na iroute na nagsasabi sa proseso ng OpenVPN kung aling kliyente ang may-ari nito. Ang kernel route lamang ang nagdadala ng mga packet sa tunnel at doon humihinto, dahil kailangan pa ring magpasya ng daemon kung aling peer ang dapat tumanggap sa kanila. Ang entry na iroute lamang ang nag-iiwan ng mga packet na iyon sa kernel na walang rutang masusundan. Ang dalawang linya ay kabilang sa konfigurasyong aktwal na nilo-load ng daemon, at sulit itong i-verify bago mag-debug ng anupamang bagay.

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

Panatilihing off ang client-to-client kapag ang kernel ang dapat na punto ng pagpapatupad ng mga tuntunin. Ang opsyong iyon ay nagpapasa ng trapiko sa pagitan ng mga peer sa loob ng daemon, na maginhawa at nangangahulugan ding hindi kailanman nakikita ng iyong mga tuntunin sa pagpapasa ang daloy. Ipinapalagay ng lahat ng nasa ibaba na nakikita ng kernel ang bawat packet sa pagitan ng mga sangay.

Bigyan ang bawat sangay ng mga rutang kailangan nito

Ang bawat sangay ay nangangailangan ng mga ruta patungo sa ibang mga sangay at sa LAN ng hub, at hindi nangangailangan ng isa patungo sa sariling konektadong LAN. Itulak ang malalayong prefix mula sa hub sa halip na idikit ang mga ito sa bawat router, upang ang ikaapat na site sa hinaharap ay mangahulugan ng isang bagong file bawat kliyente sa halip na apat na pagbabago. Nagdadala rin ang file bawat kliyente ng linyang iroute, na nagpapanatili ng pagmamay-ari at pag-anunsyo sa isang lugar. Gawing nababasa ang direktoryo at ang mga file nito ayon sa modelo ng pribilehiyo ng server, kung hindi ay nabibigo ang paghahanap nang walang mensahe.

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

Ang ikaapat na site ay sumusunod sa parehong pattern: isang natatanging awtentikadong pangalan, isang pagmamay-aring prefix, isang kernel route sa hub, isang entry na iroute, at mga anunsyo lamang sa mga site na pinapayagang maabot ito.

Subukan sa dalawang direksyon bago sabihing tapos na

I-on ang IPv4 forwarding sa lahat ng tatlong router, pagkatapos ay kumpirmahin na pinapayagan ng firewall ang nilalayong mga daloy sa dalawang direksyon, dahil ang isang-direksyong pagsubok ay pumapasa nang may sirang pabalik na landas nang mas madalas kaysa inaasahan ninuman. Sa pagitan ng mga site, hindi kailangan ang pagsasalin ng source address, at ang pagpapanatili ng orihinal na pinagmulan ang eksaktong nagpapahintulot sa bawat sangay na ilapat ang sariling patakaran sa isang kahilingan.

Subukan mula sa isang host sa LAN ng isang sangay patungo sa isang serbisyo sa isa pa, pagkatapos ay baliktarin ang direksyon, pagkatapos ay subukan mula sa isang sangay patungo sa LAN ng hub. Ang tatlong resultang iyon ay magkakaibang ebidensya, at wala sa kanila ang nagpapahiwatig ng iba. Kung ang router ng sangay ay hindi default na gateway ng sarili nitong LAN, i-install ang malalayong prefix sa tunay na gateway at isama rin ang pool kapag kailangang magsimula ng mga koneksyon ng mga kliyente ng tunnel patungo sa LAN na iyon.

Itala ang plano, ang mga file bawat kliyente at ang mga tuntunin ng firewall bilang isang dokumento, dahil ang susunod na pagdaragdag ng site ay huhusgahan batay sa mga iyon.

Nananatili ang disenyo dahil bawat antas ay may isang tungkulin: pinapanatiling natatangi ng plano ang mga prefix, inililipat ng kernel route ang mga packet, pinapangalanan ng iroute ang may-ari, at nagpapasya ang firewall kung ano ang pinapayagan. Kapag may nasira, ang listahang iyon din ang pagkakasunod-sunod ng pagsusuri.