Server o kliyente: aling yunit ng OpenVPN sa Pi na may dalawang papel

Dalawang proseso ng OpenVPN ang tumatakbo sa isang Pi na sabay na tumatanggap ng gumagala na mga gumagamit at nakakaabot sa provider sa itaas, at halos wala silang ibinabahaging anuman maliban sa hardware. Ang isa ay nakikinig sa mga papasok na tunel habang ang isa ay dumudial palabas. Bawat isa ay nagbabasa ng sariling direktoryo, at bawat isa ay may sariling paraan ng pagpalya. Ang i-restart ang mali ay ang pinakakaraniwang paraan na ang isang pag-aayos ng kliyente ay natatapos sa pagyugyog sa nakikinig sa halip.

Itugma ang pangalan ng yunit sa direktoryong niloload nito

Naghahatid ang Upstream 2.6 ng dalawang yunit ng template, [email protected] at [email protected]. Nagsisimula ang template ng server sa /etc/openvpn/server at naglo-load ng %i.conf mula roon. Nagsisimula ang template ng kliyente sa /etc/openvpn/client. Ang instans na pinangalanang roaming ay maaaring umiral sa dalawang lugar nang sabay, bilang server at bilang kliyente, na may dalawang magkaibang konfigurasyon at walang kawing sa pagitan nila maliban sa string.

Tanungin ang systemd sa halip na ang file system, dahil ang mga gumagawa ng pakete ay nagdaragdag ng mga file na makakapagbago ng gumaganang direktoryo o ng mga argumento na natatanggap ng binary.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Inililista ng unang utos ang bawat yunit na nalikha, kabilang ang mga nabigo at nanatiling nakaload. Ang ikalawa ay naglilimbag ng file ng yunit kasama ang anumang override. Ang ikatlo ay ang pinakamabilis na paraan upang makita ang dalawang katotohanan na nagpapasya sa tanong: ang direktoryo kung saan nagsisimula ang proseso, at ang landas ng konfigurasyon na ibinigay dito.

Magpasya sa direksyon ng pakete, hindi sa pangalan ng interface

Ang instans ng server ay nagmamay-ari ng nakikinig na socket at tumatanggap ng mga koneksyon. Ang naka-encrypt na transport nito ay lokal na input at lokal na output sa Pi, habang ang trapik na ipinapasa nito para sa mga gumagamit ay sumusunod sa landas ng pagpapasa at tumutugon sa ibang hanay ng mga patakaran. Ang instans ng kliyente ay walang nakikinig sa ganitong kahulugan: dumudial ito sa isang kapares, kaya ang naka-encrypt na transport nito ay lokal na output patungo sa ilalim na layer.

Sinasabi sa iyo ng pagkakaibang iyon kung saan nabibilang ang isang patakaran. Ang patakarang tumutugma sa isang interface sa loob ng kadena ng pagpapasa ay pinapayagan lamang ang trapik na napili na ng routing; hindi ito kailanman pumipili ng ruta. Kapag ang mga pakete ng gumagala na gumagamit ay lumabas sa maling daan, ang kadenang susuriin ay forward, hindi output.

Tingnan ang mga socket bago magteorya. Ang server na nakatali sa udp/1194 ay nagpapakita ng nakikinig na socket. Ang kliyente ay nagpapakita ng ugnayan sa address ng provider at walang nakikinig.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Ang default na ruta ng isang instans ay maaaring mahuli ang mga sagot ng isa pa

Ang redirect-gateway na itinutulak ng kliyente sa itaas ay naglalagay ng default na ruta na nakikipagkumpitensya sa lahat ng iba pa sa makina, kabilang ang mga sagot na ipinapadala ng server sa gumagala na mga gumagamit. Gumagawa ang OpenVPN ng eksepsyon para sa sariling address ng kapares nito upang manatiling maabot ang tunel, ngunit walang sinasabi ang eksepsyon na iyon tungkol sa teleponong nasa network ng hotel.

Ang sintomas ay karaniwang asimetriko. Natatapos ang pakikipagkamay, iniuulat ng kliyente na konektado, at namamatay ang trapik pagkatapos ng unang pakete ng sagot. Ang routing ng patakaran na batay sa pinagmulan, o isang marka ng pakete na inilagay sa instans ng server gamit ang --mark, ay naghihiwalay sa dalawang daloy; wala sa kanila ang kumpletong hanay ng mga patakaran nang mag-isa, at pareho silang nangangailangan ng wastong mga ruta sa talahanayang pinipili nila.

Subukan ang lokal na desisyon sa halip na ang kalagayan ng tunel, dahil pinipili ng kernel ang pinagmulan at interface bago makita ng OpenVPN ang pakete.

ip route get 203.0.113.44
ip rule show

I-restart ang isang papel at patunayang nakaligtas ang isa

Mahalaga ang pagkakasunod-sunod kapag ang dalawang papel ay umaasa sa parehong ilalim na layer. I-restart muna ang kliyente kung ang ruta sa itaas ay dapat umiral bago maipasa ang trapik ng mga gumagamit, at i-restart muna ang server kapag binabago mo lamang ang nakikinig nito o ang pool nito. Sa anumang kaso, kumpirmahin ang dalawang yunit pagkatapos, dahil ang nabigong pag-restart ay maaaring mag-iwan sa isa pang papel na tumatakbo sa lumang kalagayan.

Isulat ang kundisyon ng paghinto bago ang pagbabago: hinaharangan ba ng pagkawala ng tunel sa itaas ang gumagala na mga gumagamit, o bumabalik ito sa sariling uplink ng Pi? Kailangan din ng DNS at IPv6 ng malinaw na sagot, dahil ang itinulak na resolver ay madalas na nabubuhay nang mas matagal kaysa sa rutang nagpaging kapaki-pakinabang nito.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Tanggapin ang pagbabago lamang kapag tatlong bagay ang totoo nang sabay: natatapos ang isang bagong papasok na koneksyon, nakakaabot ang ipinasang aplikasyon sa destinasyon nito sa pamamagitan ng inilaan na labasan, at iniuulat pa rin ng dalawang proseso ang inaasahan nilang kapares. Kung nabigo ang isa sa tatlo, binago mo ang maling instans o maling ruta, at ang susunod na hakbang ay basahin muli ang yunit sa halip na i-restart ang anupamang bagay.