Dalawang kliyente ng OpenVPN sa isang Linux gateway: hatiin ang patakaran

Dalawang daemon ng OpenVPN ang maaaring parehong mag-ulat ng matagumpay na tunel habang ipinapadala ng gateway ang bawat kliyente sa parehong isa. Wala sa handshake ang nagpapasya kung aling tunel ang ginagamit ng kliyente; ang kernel ang nagpapasya, pakete bawat pakete, sa pagdaan sa mga tuntunin ng patakaran at pagkatapos sa talahanayang pinapangalanan ng bawat tuntunin. Kapag tiningnan ito nang ganoon, hindi na tungkol sa mga opsyon ng OpenVPN ang pagsasaayos at nagiging isang matrix ng pagruruta na may dalawang may-ari.

Ang kernel ang nagpapasya, hindi ang daemon

Dumadating ang isang ipinasa na pakete sa LAN interface at sinusuri ng routing code ang listahan ng mga tuntunin ayon sa pagkakasunod-sunod ng priyoridad. Ang unang tuntuning tumutugma ang selector ang nagpapangalan ng talahanayan, at pinipili ng mga ruta ng talahanayang iyon ang output device. Kung walang tumutugmang ruta ang talahanayan, nagpapatuloy ang paghahanap sa susunod na tuntunin, at ang detalyeng ito ang dahilan kung bakit tahimik na nabigo ang kalahating-tapos na setup sa halip na maingay.

Walang saysay ang proseso ng tunel sa pagdaang iyon. Gumagawa ito ng interface at maaaring mag-install ng mga ruta, ngunit kung papasok sa interface na iyon ang pakete ng isang partikular na kliyente ay ganap na nakasalalay sa talahanayang pinadalhan dito. Kaya nagtatagisan ang dalawang tunel na may magkaparehong inangkat na ruta, at ang huling nagsusulat ang nananalo para sa lahat. Iyon ang dahilan kung bakit maaaring magmukhang balanse ang isang setup sa mga file ng pagsasaayos at ipadala pa rin ang lahat ng kliyente sa isang daemon.

Bigyan ang bawat instance ng sariling set ng resource

Magsimula sa mga pangalan, dahil ang mga paulit-ulit na ginamit na pangalan ang paraan kung paano aksidenteng naghahati ng estado ang dalawang instance. Magtalaga ng magkakaibang tunel device, magkakaibang configuration file, magkakaibang kredensyal at magkakaibang service unit. Itala ang panlabas na endpoint at tunnel address ng bawat instance sa parehong talahanayan ng patakaran matrix, upang ang susunod na pagbabago ay may isang lugar na titingnan.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull pinapanatili ang mga rutang itinutulak ng server sa labas ng lokal na talahanayan, at iyon ang gusto mo kapag ang mga patakaran talahanayan ay dapat na tahasan. Kung ang isang partikular na server ay nagtutulak din ng redirect-gateway na opsyon, at kung sinusuportahan ng iyong bersyon ng kliyente ang filter form, sulit na suriin sa manwal sa halip na ipalagay.

Isulat ang matrix: pinagmulan, talahanayan, aparato

Para sa bawat pangkat ng kliyente, magdagdag ng tuntuning pumipili ng talahanayan ayon sa source address, pagkatapos ilagay ang inilaan na landas sa talahanayang iyon:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Kailangan ng talahanayan ang mga rutang patungo sa destinasyon na dapat mayroon ang pangkat, kasama ang anumang lokal o pangasiwaang eksepsyon na nagpapanatiling magagamit ang gateway. Ang talahanayang naglalaman lamang ng default na ruta ay patakaran ng buong tunel para sa pangkat na iyon, na maaaring eksaktong tama, ngunit dapat itong maging pasya at hindi pagkakaligtaan.

Ang sariling transportasyon ng tunel ay wala sa pangkat ng kliyente

Ang mga naka-encrypt na pakete ng bawat daemon ay nagmumula sa gateway mismo, naka-address sa panlabas na kapareha. Ang tuntuning tumutugma lamang sa isang source prefix ng kliyente ay hinahayaan ang mga paketeng iyon, kaya mas ligtas ang mga tuntuning limitado sa pinagmulan kaysa sa mga tuntuning tumutugma sa lahat. Ang tuntuning walang selector ay maaaring hulihin ang sariling transportasyon ng tunel at ibalik ito sa isang tunel, at pagkatapos ay nabigo ang koneksyon sa paraang mukhang problema ng provider.

Panatilihin ang lokal na sesyon ng pamamahala at ang landas ng ilalim na layer nang tahasan sa labas ng mga patakaran talahanayan. Isulat ang mga eksepsyon na iyon sa tabi ng matrix; bahagi sila ng disenyo, hindi isang pansamantalang solusyon na kailangang muling tuklasin sa isang insidente.

Ang pagpili ng landas ay hindi nagpapahintulot

Ang pahintulot sa pagpapasa ay pangalawang pasya na ginagawa sa bandang huli ng landas. Ang tuntunin ng firewall na tumatanggap ng mga paketeng lumalabas sa ikalawang tunel ay hindi nag-uudyok sa routing code na piliin ito, at ang tamang talahanayan ay hindi nagbibigay ng pahintulot na magpasa. Dapat mayroon ang dalawa, at ang pagsusuring nagpapatunay lamang ng isa ay magliligaw sa iyo tungkol sa isa pa. Kapag gumagana ang isang pangkat at hindi ang isa, suriin ang dalawang hakbang na iyon nang hiwalay sa halip na isulat muli ang mga talahanayan.

Ang pagsasalin ng pinagmulan ay pangatlong pasya, at dapat itong limitahan sa pangkat ng pinagmulan at sa tunel device na tunay na nagdadala nito. Magdagdag ng nakalaang chain para sa dalawang instance sa halip na i-flush ang postrouting chain, dahil ang mga walang kaugnayang serbisyo ay maaaring may mga entry doon at tinatanggal sila ng flush nang tahimik.

Ano ang nangyayari kapag bumagsak ang isang tunel

Magpasya nang maaga sa pag-uugali kapag nabigo. Kapag nawala ng isang tunel talahanayan ang ruta nito, bumabagsak ang paghahanap sa susunod na tuntunin, at nagpapatuloy ang trapiko ng pangkat sa kabilang tunel o sa karaniwang uplink nang walang anumang error. Kung hindi ito katanggap-tanggap, magdagdag ng pangwakas na tuntunin na may mas mababang priority number na nagbabalik ng hindi maabot na resulta para sa pinagmulang iyon, upang makita ang pagkawala sa halip na masipsip.

Magpadala ng bagong kahilingan mula sa bawat pangkat ng pinagmulan at itala ang apat na katotohanan: ang napiling talahanayan, ang output device, ang isinaling pinagmulan, at kung bumalik ba ang tugon sa parehong landas. Pagkatapos ay ibaba ang isang tunel at ulitin. Ang dalawang TUN device sa listahan ng interface ay nagpapatunay na nagsimula ang dalawang daemon; wala silang sinasabi tungkol sa kung alin ang ginamit ng isang partikular na kliyente. Ang pangalawang pagtakbo, na may isang tunel na wala, ang siyang nagpapakita kung ginagawa ng iyong fallback rule ang inilaan.