Gumagana lang ang VPN mo pagkatapos mag-login dahil sa keyring

Gumagana ang command kapag naka-login ka, kaya inilalagay mo ito sa startup script at umuuwi. Kinabukasan, online ang makina at wala ang tunnel. Ang alamat ay ang gumaganang invocation ay gumaganang serbisyo. Sa praktika, ang pagkakaiba ay karaniwang isa sa dalawang bagay: pag-aari ng session mo ang profile, hindi ng system, o ang sikreto ay binubuksan ng isang bagay na umiiral lamang pagkatapos mong mag-login. Pareho silang gumagana nang perpekto sa manu-manong pagsubok at nabibigo sa eksaktong sandaling walang nanonood.

Bakit ginagawa nitong gumana ang login

Ang graphical login ay nagbubukas ng session bus at agent ng secret service, at doon iniimbak ng maraming desktop-oriented na client ang password ng profile o ang passphrase ng private key. Ang activation na tumatakbo bilang user mo pagkatapos mag-login ay maaaring humingi ng sikreto sa agent na iyon at magtagumpay. Ang parehong activation na isinasagawa ng boot-time unit ay walang session, bus at agent, kaya nabibigo ang paghahanap o bumabara sa isang prompt na walang nakakakita.

Patakbuhin ang parehong profile bago at pagkatapos mag-login at makakakuha ka ng dalawang magkaibang resulta mula sa isang configuration. Iyan ang pirma ng pagdepende sa kredensyal, hindi ng sirang tunnel, at ipinapaliwanag nito kung bakit ang manu-manong pagsubok sa terminal ay nagpapatunay ng mas kaunti kaysa sa hitsura nito. Maayos ang tunnel; kulang ang bagay na nagbubukas ng sikreto nito.

Magpasya kung sinong may-ari ang nagbubukas ng tunnel

May dalawang sinusuportahang pattern, at ang paghahalo sa kanila ang isa pang paraan para mabigo ito. Maaaring i-activate ng NetworkManager ang koneksyong saklaw ng system, na angkop kapag ang makina ay nagsesentralisa na ng network doon. Bilang alternatibo, ang isang dedikadong systemd unit ay direktang nagpapatakbo ng VPN at pag-aari nito ang interface.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

Huwag patakbuhin ang dalawang may-ari laban sa isang configuration. Kung pinamamahalaan ng NetworkManager ang interface at itinataas din ito ng unit, mag-aaway sila sa mga ruta at DNS, at ang resultang estado ay depende sa kung sino ang huling natapos.

Ilagay ang sikreto kung saan mababasa ito ng serbisyo

Ang serbisyong nasa background ay hindi makakasagot sa prompt. Ang mga passphrase ng certificate, password ng account at referenced na auth file ay lahat nangangailangan ng kaayusan ng imbakan na maabot ng unit nang walang tao, pag-aari ng account na nagpapatakbo ng serbisyo at hindi mabasa ng iba.

Ang tuksong shortcut ay gawing nababasa ng lahat ang file hanggang mawala ang error sa pahintulot. Ipinagpapalit niyon ang kabiguan sa boot para sa pangmatagalang pagkakalantad ng kredensyal, at ito ang uri ng pagbabagong walang bumabalik. Gamitin ang mekanismong pinagkakatiwalaan na ng deployment: isang limitadong file ng kredensyal, isang hindi naka-encrypt na key na protektado ng mga pahintulot ng file, o isang koneksyong saklaw ng system na may sariling imbakan ng sikreto.

Subukan ang pangyayaring talagang nangyayari

Ang manu-manong pag-start ng serbisyo pagkatapos mag-login ay halos walang sinusubukan. I-reboot, o huwag paganahin ang graphical login sa isang cycle, at panoorin ang unit na bumangon nang mag-isa. Ito ang tanging pagsubok na nagsasanay nang sabay sa pagkakaroon ng kredensyal, kahandaan ng network at pagkakasunod-sunod ng unit. Ito rin ang pagsubok na nagreproduce ng kabiguang iniulat ng user, na hindi kailanman ginagawa ng manu-manong pag-start.

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

Ang pagkakasunod-sunod ay kasinghalaga ng kredensyal. Ang unit na nagsisimula bago ma-configure ang pinagbabatayang uplink ay susuko, at ang ilang distribusyon ay magkaiba kung naghihintay sila ng konektibidad. Kung ang unit ay nag-uulat ng kabiguan sa boot ngunit nagtatagumpay kapag sinimulan gamit ang kamay pagkalipas ng tatlumpung segundo, natagpuan mo ang problema sa pagkakasunod-sunod at hindi problema sa sikreto.

I-verify ang mga ruta at DNS, hindi lang ang interface

Ang interface na umiiral ay hindi gumaganang tunnel. Pagkatapos ng start na walang nagmamasid, suriin ang mga ruta, ang estado ng resolver at isang destinasyon ayon sa address bago suriin ang isang pangalan. Pagkatapos suriin ang application kung saan umiiral ang tunnel.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Kung gumagana ang address at hindi ang pangalan, ang natitirang problema ay patakarang DNS at hindi ang tunnel. Itala kung sinong may-ari ang nagbubukas ng serbisyo at saan nakatira ang sikreto, dahil ang susunod na taong mag-reboot ng makinang ito ay mangangailangan ng dalawang katotohanan.