Nahihinto ang kliyente ng OpenVPN kapag tumatakbo ang server nito sa parehong host

Mayroon akong lab machine na tumatanggap ng tunnel mula sa malayong site at dumidial din palabas sa network ng vendor. Gumana ang outbound profile nang ilang linggo. Matapos idagdag ang inbound server, kumonekta ang outbound at pagkatapos ay tumigil sa pagpapadala ng trapiko sa loob ng ilang segundo, o tumanggi itong magsimula na may error na ang address ay ginagamit na. Hindi nagbago ang mga config file; nagkaroon lang ang host ng pangalawang proseso ng OpenVPN na may sariling opinyon tungkol sa mga port at ruta.

Ang pagkabigo ay hindi random, at hindi ito problema sa authentication. Dalawang daemon sa isang machine ang nag-aagawan sa parehong lokal na socket at parehong routing table, at ang huling nagsimula o muling kumonekta ang kadalasang nananalo. Ang pag-alam kung alin sa dalawang banggaan na ito ang mayroon ka ang nagtatakda kung saan titingin muna.

Basahin ang sintomas nang pabaliktad

Magsimula sa kung kailan namamatay ang tunnel. Ang bind error sa pagsisimula ay tumutukoy sa panig na nakikinig: may nagmamay-ari na sa port na iyon, at tumatanggi ang OpenVPN na magsimula sa halip na ibahagi ito. Ang tunnel na bumabangon at pagkatapos ay tumatahimik ay tumutukoy sa routing, dahil ang rutang inilagay ng kabilang instance ay maaaring humatak sa mga packet ng panlabas na koneksyon palayo sa kanilang landas.

Pareho ang reklamo ng user na nagmumula sa dalawang kaso, kaya walang naaayos ang mga retry loop at watchdog script. Ikinokonekta nila muli ang kliyente sa parehong banggaan. Ang kapaki-pakinabang na unang tanong ay kung tumatakbo pa ang proseso kapag huminto ang trapiko.

Isang socket at isang device bawat instance

Ang server na nakikinig ay nagbubuklod ng port nito; ang outbound client ay nangangailangan din ng lokal na port para sa naka-encapsulate nitong trapiko. Kapag pareho silang nakatira sa isang host, maaaring mabangga ng default na pag-uugali ng kliyente ang port ng server. Maaaring i-pin ang lokal na port ng kliyente, at maaaring laktawan ang pagbubuklod kung saan hindi kailangan ng kapares ang nakapirming source port:

lport 1195
nobind
dev tun1

Ang mga numerong iyon ay halimbawa, hindi kinakailangan. Ang mahalaga ay tumigil ang kliyente sa pag-aagawan sa port ng server at bawat instance ay makakuha ng hiwalay na tunnel device. Dalawang daemon na nagbabahagi ng tun0 ay nagsusulat sa isa't isa ng estado ng device kahit magkaiba ang kanilang mga port, kaya ang isang device bawat tunnel ay hindi opsyonal.

nobind ay kabilang sa panig ng kliyente. Kailangan pa ring magbuklod at makinig ng server, kaya huwag kopyahin ang linya sa config ng server, at huwag i-disable ang pagbubuklod sa kliyenteng ang kapares ay nag-filter sa nakapirming source port.

Pumili ng isang may-ari para sa default na ruta

Isang koneksyon lang ang makakapaglagay ng default na ruta. Kung parehong profile ang nagre-redirect ng lahat ng trapiko, tahimik na pinapalitan ng pangalawang koneksyon ang una, at ang una ay tila nasisira. Panatilihing hati ang outbound tunnel at itulak lamang ang mga prefix ng vendor, o bigyan ito ng hiwalay na routing table.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Ang mga address at numero ng table sa itaas ay mga placeholder. Kaagad pagkatapos idagdag ang panuntunan, tiyakin na ang address ng VPN server mismo ay nalulutas pa rin sa normal na table; ang table na humahawak sa panlabas na transport ay sumisira sa tunnel na dapat nitong protektahan, at ang sumusunod na reconnect loop ay mukhang hindi mapagkakatiwalaang provider.

Para sa setup na kailangang mabuhay sa mga reconnect at reboot, ang network namespace ang mas matibay na hangganan. Ang pangalawang kliyente ay tumatakbo sa loob ng sarili nitong namespace kasama ang sariling mga interface at ruta, at ang mga serbisyong kailangang tumawid lamang ang inilalantad. Ang host ay nagpapanatili ng isang default na ruta, at ang reconnect ng namespace ay hindi ito maisusulat muli.

I-verify gamit ang table, hindi ang status line

Ang kliyenteng nag-uulat na konektado ay nagpapatunay lamang ng control channel nito. Kunin ang estado ng routing bago at pagkatapos ng bawat koneksyon, pagkatapos ay tanungin ang kernel kung aling device ang gagamitin ng tunay na destinasyon:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

Kung nagbabago ang napiling device para sa address ng vendor kapag nagsimula ang pangalawang tunnel, mayroon kang banggaan ng ruta. Kung parehong lumilitaw ang dalawang proseso sa parehong lokal na port, mayroon kang banggaan ng socket. Ang pag-aayos ng una nang wala ang pangalawa ay naglilipat lamang ng pagkabigo sa susunod na reconnect.

Isulat ang mga port, device, table at may-ari ng ruta sa runbook ng host. Kung hindi, ang susunod na taong magdadagdag ng pangatlong tunnel ay muling matutuklasan ang parehong banggaan, at ang tanging nakikitang ebidensya ay isang koneksyong gumagana hanggang sa mag-restart ang daemon ng ibang tao.