Dalawang OpenVPN client sa isang Linux host: kanino ang ruta?

Parehong nag-uulat ng koneksyon ang dalawang profile at ang isa sa kanila ay tahimik na nagdadala ng trapikong para sa isa pa. Ang dalawang client sa isang host ay isang sinusuportahang kaayusan; ang dalawang client na walang may-ari para sa bawat prefix ay hindi. Ang gawain ay hindi gaanong tungkol sa pag-angat ng pangalawang tunnel kundi sa pagpapasya kung aling proseso ang maaaring mag-angkin ng aling ruta. Sundin ang pagkakasunod-sunod sa ibaba at ang configuration ay susunod mula sa mga sagot.

Magsimula sa pagtatanong kung para saan ang pangalawang tunnel

Tatlong sitwasyon ang magkamukha sa status line at nangangailangan ng magkakaibang disenyo. Ang paghahati ayon sa destinasyon ay nagpapadala ng isang prefix sa pamamagitan ng profile ng opisina at isa pa sa pamamagitan ng profile ng laboratoryo, na walang alinman sa kanila ang nag-aangkin ng default na ruta. Ang paghahati ayon sa aplikasyon ay karaniwang nagpapanatili ng isang buong tunnel at itinuturo ang partikular na trapiko gamit ang mga tuntunin ng patakaran. Ang failover ay nagpapanatili ng eksaktong isang tunnel na aktibo sa isang pagkakataon, na nangangahulugang ang pangalawa ay hindi dapat awtomatikong magsimula.

Isulat ang kaso bago buksan ang anumang configuration file, dahil ang sagot na iyon ang nagpapasya sa lahat ng susunod.

Ang pinakakaraniwang sirang kaayusan ay dalawang buong tunnel na parehong nagtulak ng default na ruta, kung saan nananalo ang huling kumonekta at ang una ay patuloy na nagpapanggap. Ang estadong iyon ay mukhang sinadya mula sa status line at nagsasayang ng isang araw mula sa routing table. Ang pagpangalan sa kaso muna ay ginagawa itong imposible kaysa lamang malabong mangyari.

Tingnan ang mga pool bago ang mga ruta

Ang dalawang server ay madaling makapagbigay ng mga address mula sa isang pribadong saklaw, at kapag ginawa nila iyon, ang client ay nagtatapos na may dalawang interface sa loob ng isang prefix. Wala nang destinasyon ang maaaring iugnay sa isang interface ayon sa address, dahil pareho silang mukhang tama. Muling bilangin ang isang pool sa halip na mag-imbento ng tuntunin para basagin ang tabla.

Suriin din ang lokal na network, dahil ang LAN sa bahay o opisina na nagsasapaw sa saklaw ng tunnel ay lumilikha ng parehong kalabuan mula sa kabilang panig. Ihambing ang mga address sa host sa dalawang configuration ng server bago sisihin ang client. Ang pagbabago ng pool sa isang laboratory server ay limang minutong pagwawasto, samantalang ang pag-iwas sa pamamagitan ng routing ayon sa patakaran para sa nagsasapaw na prefix ay permanenteng buwis sa lahat ng magbabasa ng configuration mamaya. Magpasya kung alin sa dalawa ang gusto mo bago pumili kung saan makikialam.

Dalawang pamilya ng address ang ibig sabihin ng dalawang pag-ikot ng pagsusuring ito. Ang mga pool ng IPv6 ay bumabangga nang kasing tahimik ng IPv4.

Bigyan ang bawat profile ng may-ari

Isang instance bawat profile, isang configuration file bawat instance at isang pangalan na kumikilala sa pares. Sa packaging na istilong Debian, pinipili ng pangalan pagkatapos ng tandang @ ang file, kaya ang dalawang profile na nagbabahagi ng pangalan ng instance ay hindi kailanman maaaring gumana kapwa. Kumpirmahin ang mapping mula sa naka-install na unit, hindi mula sa tutorial.

systemctl cat [email protected]
ip -4 addr show

Pagkatapos ay magpasya kung sino ang nag-i-install ng mga ruta, na isang usapin ng patakaran at hindi ng syntax.

Kapag ang dalawang server ay nagtulak ng hindi magkatugmang set, alinman sa magdagdag route-nopull at ilista lamang ang mga prefix na kailangan ng bawat profile, o hayaang panatilihin ng isa ang default na ruta nito at ituon ang natitira gamit ang tuntunin ng patakaran. Dalawang proseso na parehong nag-i-install ng default na ruta ay nagtatapos sa isang panalo at walang makapagsasabi kung bakit. Sa sandaling ang dalawang tunnel ay nagdadala ng trapiko para sa magkaibang pinagmulan, ang tugon ay maaaring lumabas sa maling tunnel, at ang pattern na nananatili ay isang marka ng koneksyon na naibalik sa mga tugon at itinuro sa sarili nitong talahanayan. Limitahan ang mga marka upang ang sariling naka-encrypt na packet ng mga tunnel ay hindi kailanman tumugma sa kanila.

I-verify bawat tunnel, pagkatapos ay ihinto ang isa

Kapag pareho nang nakaangat, kumuha ng tatlong pagbasa: ang address sa bawat tunnel device, ang ruta patungo sa host na nakatira sa likod ng bawat isa, at ang landas na tatahakin ng destinasyong labas sa dalawa. Ang ordinaryong listahan ng ruta ay humihinto sa paglalarawan ng huling paghahanap sa sandaling pumasok ang mga tuntunin, kaya tanungin ang kernel kung ano talaga ang pipiliin nito. Pagkatapos ay ihinto ang isang instance at panoorin kung ano ang nawawala. Kung ang paghinto sa una ay nakakagambala sa pangalawa, may bagay pa ring ibinabahagi sa pagitan nila: isang ruta, isang pangalan ng device, o isang tuntunin ng firewall na walang naghiwalay.

ip rule show
ip route get 203.0.113.9

Ibalik ang hintong profile at ulitin ang parehong pagsusuri, dahil ang tunnel na gumagana nang isang beses pagkatapos ng reboot at hindi na kailanman ay isang bug sa lifecycle na nakasuot ng kasuutan ng routing.

Itala sa mga tala ng deployment kung aling profile ang may-ari ng aling prefix, sa tabi ng mga saklaw ng pool. Ang dalawang tunnel ay isang sinadyang kaayusan, at kailangang makita ng susunod na mambabasa ang hangganan bago hawakan ang alinmang profile. Kung wala ang talang iyon, ang hangganan ay muling natutuklasan ng sinumang naka-duty kapag sa wakas ay nasira ang ibinabahaging prefix.