Jūsų VPN veikia tik po prisijungimo dėl raktų saugyklos

Komanda veikia, kai esate prisijungę, todėl įdedate ją į paleidimo scenarijų ir einate namo. Kitą rytą mašina yra prisijungusi prie tinklo, o tunelis – ne. Mitas yra tai, kad veikiantis iškvietimas yra veikianti paslauga. Praktiškai skirtumas paprastai yra vienas iš dviejų dalykų: profilis priklauso jūsų naudotojo sesijai, o ne sistemai, arba paslaptį atrakina kažkas, kas egzistuoja tik po to, kai prisijungiate. Abu puikiai veikia rankiniame bandyme ir nepavyksta būtent tuo metu, kai niekas nežiūri.

Kodėl prisijungimas leidžia jam veikti

Grafinis prisijungimas paleidžia sesijos magistralę ir paslapčių tarnybos agentą, ir būtent ten daugelis darbalaukiui skirtų klientų laiko profilio slaptažodį ar privataus rakto slaptafrazę. Aktyvavimas, kuris po prisijungimo veikia kaip jūsų naudotojas, gali paprašyti to agento paslapties ir pavykti. Tas pats aktyvavimas, kurį atlieka paleidimo įrenginys, neturi sesijos, magistralės ir agento, todėl paieška nepavyksta arba užblokuoja niekam nematomą užklausą.

Paleiskite tą patį profilį prieš ir po prisijungimo ir gausite du skirtingus rezultatus iš vienos konfigūracijos. Tai yra priklausomybės nuo prisijungimo duomenų ženklas, o ne sugedusio tunelio, ir paaiškina, kodėl rankinis bandymas terminale įrodo mažiau, nei atrodo. Tunelis yra tvarkingas; trūksta to, kas atrakina jo paslaptį.

Nuspręskite, kuris savininkas paleidžia tunelį

Yra du palaikomi šablonai, o jų maišymas yra kitas būdas, kaip tai nepavyksta. NetworkManager gali suaktyvinti sistemos lygmens ryšį, kas tinka, kai mašina jau ten centralizuoja savo tinklą. Arba specialus systemd įrenginys tiesiogiai paleidžia VPN ir pats valdo sąsają.

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

Neleiskite abiejų savininkų su viena konfigūracija. Jei NetworkManager valdo sąsają, o įrenginys ją taip pat pakelia, jie kovos dėl maršrutų ir DNS, o galutinė būsena priklauso nuo to, kas baigė paskutinis.

Padėkite paslaptį ten, kur paslauga gali ją perskaityti

Fono paslauga negali atsakyti į užklausą. Sertifikatų slaptafrazės, paskyrų slaptažodžiai ir nurodyti autentifikavimo failai visiems reikia tokio saugojimo išdėstymo, kurį įrenginys pasiektų be žmogaus, kuris priklausytų paskyrai, paleidžiančiai paslaugą, ir būtų neperskaitomas visiems kitiems.

Viliojantis trumpasis kelias yra padaryti failą skaitomą visiems, kol teisių klaida išnyks. Tai iškeičia paleidimo nesėkmę į ilgalaikį prisijungimo duomenų atskleidimą, ir tai yra tokio pobūdžio pakeitimas, prie kurio niekas negrįžta. Naudokite mechanizmą, kuriuo diegimas jau pasitiki: apribotą prisijungimo duomenų failą, neužšifruotą raktą, apsaugotą failo teisių, arba sistemos lygmens ryšį su savo slaptų duomenų saugykla.

Išbandykite įvykį, kuris iš tikrųjų vyksta

Rankinis paslaugos paleidimas po prisijungimo beveik nieko netikrina. Paleiskite iš naujo arba vienam ciklui išjunkite grafinį prisijungimą ir stebėkite, kaip įrenginys pakyla pats. Tai vienintelis bandymas, kuris kartu tikrina prisijungimo duomenų prieinamumą, tinklo parengtį ir įrenginių tvarką. Tai taip pat bandymas, kuris atkuria naudotojo praneštą nesėkmę, ko rankinis paleidimas niekada nepadaro.

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

Tvarka svarbi tiek pat, kiek prisijungimo duomenys. Įrenginys, kuris paleidžiamas anksčiau, nei sukonfigūruotas pagrindinis išėjimo ryšys, pasiduos, o kai kurios distribucijos skiriasi tuo, ar laukia ryšio. Jei įrenginys paleidimo metu praneša apie nesėkmę, bet pavyksta, kai po trisdešimties sekundžių jį paleidžiate rankiniu būdu, radote tvarkos problemą, o ne paslapties problemą.

Tikrinkite maršrutus ir DNS, ne tik sąsają

Egzistuojanti sąsaja nėra veikiantis tunelis. Po priežiūros nepaleisto paleidimo patikrinkite maršrutus, sprendėjo būseną ir vieną paskirties tašką pagal adresą prieš tikrindami vardą. Tada patikrinkite programą, kuriai tunelis egzistuoja.

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'

Jei adresas veikia, o vardas ne, likusi problema yra DNS politika, o ne tunelis. Užsirašykite, kuris savininkas paleidžia paslaugą ir kur gyvena paslaptis, nes kitam žmogui, kuris paleis šią mašiną iš naujo, prireiks abiejų faktų.