Wêrom jo OpenVPN-klant nei ien time-out del bliuwt
In klant dy't by de earste time-out fuortgiet, lit in host efter dy't online liket en neat draacht. Reparearje de profylopsje en it werstartbelied apart.
Moandei moarns: de tunnel dy't freed omheech kaam is fuort, de ynterface stiet noch yn 'e list, en yn it logboek stiet neat dat immen it murken hat. De host is online, it dashboerd is grien, en alles wat er yn it wykein stjoerd hat, gie ynstee troch de fysike ynterface nei bûten. Hjir ûntbrekke twa ûnôfhinklike besluten: ien oer de fraach oft it klantproses in tydlike flater oerlibbet en ien oer de fraach oft eat boppe him it proses nei syn fuortgong wer start. Allinnich ien fan beide reparearje lit de oare kleau iepen.
Begjin by wat de unit eins die, net by wat de monitoring beweart. systemctl status openvpn-client@office en journalctl -u openvpn-client@office -n 50 litte de reden fan it fuortgean en de lêste regel sjen dy't de klant skreau foardat er fuortgie.
It proses gie fuort foardat immen it murken
In klant dy't sûnder flater ferdwynt, is meastentiids mei opsetsin fuortgien. It profyl beslút oer dat gedrach, net de tsjinstbehearder: ping-exit einiget it proses sa gau't de oare partij ophâldt mei antwurdzjen, wylst ping-restart it proses hâldt en him der yn wer ferbynt. Sesjeheinen en ynaktiviteitstimers jouwe fan bûten itselde byld: gjin tunnel en gjin alarm.
De twa ping-direktiven kinne net tagelyk yn ien profyl stean, dus kies ien en skriuw de kar op. Sjoch ek nei de tsjinner, want syn eigen ping-exit slút in sesje ôf wat de klant ek frege hat, en allinnich it tsjinnerlogboek skriuwt op wa't dat beslút naam.
Kieze tusken ping-exit en ping-restart
Kies ping-restart foar in laptop of in ôfstân lizzend plak dat himsels genêze moat, en hâld ping-exit foar gefallen wêr't in deade tunnel it proses stopje moat sadat eat oars derop reagearje kin. De sifers binne minder wichtich as de relaasje: ping 10 mei ping-restart 60 betsjut tsien sekonden stilte foar in probe en sechstich foar de werstart, wat agressyf is op in ferliesrike mobile ferbining en ridlik op in triedden iene. Skriuw de reden njonken de regel, oars sil de folgjende lêzer oannimme dat de standertwearden mei opsetsin wiene.
Befêstigje dan dat it proses it is dat fuortgien is. In unit dy't aktyf rapportearret wylst de tunnel dea is, is in oare flater, dy't hjirûnder behannele wurdt.
Tafersjoch dat de unit echt wer start
Op in systemd-host is de lytste bliuwende feroaring ien drop-in-bestân: Restart=on-failure en RestartSec=10 yn /etc/systemd/system/[email protected]/restart.conf. In drop-in wurdt allinnich lêzen as systemd syn eigen definysjes wer ladt, rin dan dêrnei systemctl daemon-reload. Ferifiearje mei systemctl show -p Restart -p ExecMainStatus openvpn-client@office ynstee fan oan te nimmen dat de wearde oankaam. De ynstânsje yn 'e bestânsnamme moat it profyl wêze dat de unit echt ladt, dus in bestân skreaun foar office docht neat foar openvpn-client@home.
on-failure negearret ien gefal: in skjinne fuortgong mei status nul. Guon ôfbrekpaden einigje sa, lês dêrom de fêstleine status ynstee fan de bewurding fan in man-side te fertrouwen. As jo klant mei in nul opjout, hawwe jo Restart=always nedich, en de priis is dat in echt stikken profyl hieltyd weromkomt oant de starttempo-limyt ta slacht en it logboek fol rekket.
Restart=always slacht ek ta nei in bewuste stop. Brûk systemctl stop foar ûnderhâld, en maskearje de unit as dy dellizze moat wylst jo wurkje.
Fang it lek wylst de tunnel del is
Tafersjoch hâldt de tunnel weromkommend; it stopet ferkear net om fuort te gean wylst de tunnel fuort is. persist-tun hâldt it apparaat en syn rûtes oer werferbiningen hinne, wat handich is en in finster iepenet. It apparaat oerlibbet, de rûtes rjochtsje noch op him, en pakketten driigje ûnbeskerme en ûnrapportearre nei bûten. Dat is in beliedskeuze, net in neutrale standert.
As in host hielendal gjin ûnbeskerme pakketten útstjoere mei, kin allinnich de firewall dat garandearje. In útgongsregel dy't de tunnelynterface en it adres fan 'e VPN-tsjinner tastiet en al it oare ferdwynt, hâldt noch nei't de klant dea is, en neat yn 'e eigen konfiguraasje fan 'e klant kin ferkear filterje dat de klant net draacht.
Test it troch de klant mei opsetsin te stopjen. Rin systemctl stop openvpn-client@office, dan curl -m 5 https://example.com, dat oer de fysike ferbining mislearje moat ynstee fan te slagjen. In sukses betsjut dat de firewallregel ûntbrekt of te tastienend is.
Ferbinje wer, befêstigje dat de tunnel wer ferkear draacht, en foegje de kontrôle pas dan oan 'e monitoring ta. It polljen fan ip addr fan cron foar in tun-apparaat is it tafersjoch dat it faakst mislearret, want mei persist-tun oerlibbet it apparaat de sesje en rapportearret de probe sûnens wylst der neat droegen wurdt.