Serveris ar klientas: kuris OpenVPN vienetas dviejų vaidmenų Pi

Viename Pi veikia du OpenVPN procesai, kuris kartu priima klajojančius naudotojus ir pasiekia aukštesnį tiekėją, ir jie beveik nieko bendro neturi, išskyrus techninę įrangą. Vienas klausosi įeinančių tunelių, kitas skambina į išorę. Kiekvienas skaito savo katalogą ir kiekvienas turi savo gedimo režimą. Netinkamo vieneto paleidimas iš naujo yra dažniausias būdas, kuriuo kliento pataisymas vietoj to sukrečia klausytoją.

Suderinkite vieneto pavadinimą su katalogu, kurį jis įkelia

Upstream 2.6 pateikia du šabloninius vienetus, [email protected] ir [email protected]. Serverio šablonas paleidžiamas /etc/openvpn/server kataloge ir iš ten įkelia %i.conf. Kliento šablonas paleidžiamas /etc/openvpn/client kataloge. Instance, vardu roaming, gali egzistuoti abiejose vietose vienu metu, kaip serveris ir kaip klientas, su dviem nesusijusiomis konfigūracijomis ir be jokio ryšio tarp jų, išskyrus eilutę.

Klauskite systemd, o ne failų sistemos, nes pakuočių kūrėjai prideda papildomų failų, galinčių pakeisti darbinį katalogą arba argumentus, kuriuos gauna binarių failas.

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

Pirmoji komanda išvardija kiekvieną sukurtą vienetą, įskaitant tuos, kurie nepavyko ir liko įkelti. Antroji išspausdina vieneto failą su bet kokiu perrašymu. Trečioji yra greičiausias būdas pamatyti du faktus, kurie nusprendžia klausimą: katalogą, kuriame procesas prasideda, ir konfigūracijos kelią, kuris jam buvo duotas.

Spręskite pagal paketų kryptį, o ne pagal sąsajos pavadinimą

Serverio instancija turi klausymosi lizdą ir priima ryšius. Jos šifruotas transportas yra vietinis įėjimas ir vietinis išėjimas Pi, o srautas, kurį ji persiunčia naudotojams, eina persiuntimo keliu ir paklūsta kitam taisyklių rinkiniui. Kliento instancija tokiu požiūriu klausytojo neturi: ji skambina partneriui, todėl jos šifruotas transportas yra vietinis išėjimas link apatinio sluoksnio.

Šis skirtumas pasako, kur priklauso taisyklė. Taisyklė, atitinkanti sąsają persiuntimo grandinėje, tik leidžia srautą, kurį maršrutizavimas jau pasirinko; ji niekada nepasirenka maršruto. Kai klajojančio naudotojo paketai išeina netinkamu keliu, grandinė, kurią reikia tikrinti, yra forward, o ne output.

Pažiūrėkite į lizdus prieš teoretizuodami. Serveris, susietas su udp/1194, rodo klausymosi lizdą. Klientas rodo asociaciją su tiekėjo adresu ir nieko, kas klausytųsi.

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

Vienos instancijos numatytasis maršrutas gali pagauti kitos atsakymus

redirect-gateway, kurį stumia aukštesnis klientas, įdiegia numatytąjį maršrutą, kuris konkuruoja su viskuo kitu mašinoje, įskaitant atsakymus, kuriuos serveris siunčia klajojantiems naudotojams. OpenVPN daro išimtį savo partnerio adresui, kad tunelis liktų pasiekiamas, bet ta išimtis nieko nesako apie telefoną viešbučio tinkle.

Simptomas paprastai būna asimetriškas. Rankos paspaudimas baigiasi, klientas praneša apie ryšį, ir srautas miršta po pirmojo atsakymo paketo. Šaltiniu pagrįstas politikos maršrutizavimas arba paketo žymė, nustatyta serverio instancijoje su --mark, laiko du srautus atskirai; nė vienas pats savaime nėra visas taisyklių rinkinys, ir abiem reikia galiojančių maršrutų lentelėje, kurią jie pasirenka.

Tikrinkite vietinį sprendimą, o ne tunelio būseną, nes branduolys pasirenka šaltinį ir sąsają anksčiau, nei OpenVPN pamato paketą.

ip route get 203.0.113.44
ip rule show

Paleiskite iš naujo vieną vaidmenį ir įrodykite, kad kitas išliko

Tvarka svarbi, kai abu vaidmenys priklauso nuo to paties apatinio sluoksnio. Pirmiausia paleiskite iš naujo klientą, jei aukštesnis maršrutas turi egzistuoti prieš persiunčiant naudotojų srautą, o pirmiausia paleiskite iš naujo serverį, kai keičiate tik jo klausytoją arba jo baseiną. Bet kuriuo atveju po to patvirtinkite abu vienetus, nes nepavykęs paleidimas iš naujo gali palikti kitą vaidmenį veikiantį su pasenusia būsena.

Užsirašykite sustabdymo sąlygą prieš pakeitimą: ar viršutinio tunelio praradimas blokuoja klajojančius naudotojus, ar grįžtama prie paties Pi viršutinės jungties? DNS ir IPv6 taip pat reikia aiškaus atsakymo, nes įstumtas sprendėjas dažnai išgyvena ilgiau nei maršrutas, kuris padarė jį naudingu.

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

Priimkite pakeitimą tik kai trys dalykai galioja vienu metu: naujas įeinantis ryšys baigiamas, persiųsta programa pasiekia tikslą per numatytą išėjimą, ir abu procesai vis dar praneša apie savo laukiamą partnerį. Jei vienas iš trijų nepavyksta, pakeitėte netinkamą instanciją arba netinkamą maršrutą, ir kitas žingsnis yra perskaityti vienetą iš naujo, o ne paleisti ką nors kita.