VPN-ja juaj funksionon vetëm pas identifikimit për shkak të vargut të çelësave

Komanda funksionon kur jeni i identifikuar, ndaj e vendosni në një skript nisjeje dhe shkoni në shtëpi. Të nesërmen në mëngjes makina është në linjë dhe tuneli jo. Miti është se një thirrje që funksionon është një shërbim që funksionon. Në praktikë ndryshimi është zakonisht një nga dy gjëra: profili i përket sesionit tuaj të përdoruesit dhe jo sistemit, ose sekreti zhbllokohet nga diçka që ekziston vetëm pasi të identifikoheni. Të dyja funksionojnë në mënyrë të përsosur në një test manual dhe dështojnë pikërisht në momentin kur askush nuk po shikon.

Pse identifikimi e bën të funksionojë

Një identifikim grafik nis një bus sesioni dhe një agjent të shërbimit të sekreteve, dhe atje shumë klientë të orientuar drejt desktopit mbajnë fjalëkalimin e profilit ose frazën e kalimit të çelësit privat. Një aktivizim që ekzekutohet si përdoruesi juaj pas identifikimit mund t'i kërkojë atij agjenti sekretin dhe të ketë sukses. I njëjti aktivizim i ekzekutuar nga një njësi nisjeje nuk ka sesion, bus dhe agjent, kështu që kërkimi dështon ose bllokohet në një kërkesë që askush nuk e sheh.

Ekzekutoni të njëjtin profil para dhe pas identifikimit dhe merrni dy rezultate të ndryshme nga një konfigurim i vetëm. Ky është nënshkrimi i një varësie nga kredencialet, jo i një tuneli të prishur, dhe shpjegon pse një test manual në terminal provon më pak sesa duket. Tuneli është në rregull; mungon ajo që zhbllokon sekretin e tij.

Vendosni cili pronar e nis tunelin

Ka dy modele të mbështetura, dhe përzierja e tyre është mënyra tjetër se si kjo dështon. NetworkManager mund të aktivizojë një lidhje në nivel sistemi, e cila është e përshtatshme kur makina tashmë e centralizon rrjetin atje. Ose, një njësi systemd e dedikuar e ekzekuton VPN-në drejtpërdrejt dhe zotëron vetë ndërfaqen.

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

Mos i ekzekutoni të dy pronarët mbi një konfigurim. Nëse NetworkManager menaxhon ndërfaqen dhe një njësi gjithashtu e ngre atë, ata do të zihen për rrugët dhe DNS, dhe gjendja që rezulton varet nga kush përfundoi i fundit.

Vendoseni sekretin aty ku një shërbim mund ta lexojë

Një shërbim në sfond nuk mund t'i përgjigjet një kërkese. Frazat e kalimit të certifikatave, fjalëkalimet e llogarive dhe skedarët e referuar të vërtetimit kanë të gjithë nevojë për një rregullim magazinimi që njësia mund ta arrijë pa një njeri, në pronësi të llogarisë që ekzekuton shërbimin dhe të palexueshme për të gjithë të tjerët.

Shkurtesa joshëse është ta bësh skedarin të lexueshëm nga të gjithë derisa gabimi i lejeve të zhduket. Kjo shkëmben një dështim nisjeje me një ekspozim afatgjatë të kredencialeve, dhe është lloji i ndryshimit që askush nuk e rishikon. Përdorni mekanizmin të cilin vendosja tashmë i beson: një skedar kredencialesh i kufizuar, një çelës i paenkriptuar i mbrojtur nga lejet e skedarit, ose një lidhje në nivel sistemi me depon e vet të sekreteve.

Provoni ngjarjen që ndodh me të vërtetë

Nisja e shërbimit manualisht pas identifikimit nuk teston pothuajse asgjë. Rinisni, ose çaktivizoni identifikimin grafik për një cikël, dhe shikoni njësinë duke u ngritur vetë. Ky është testi i vetëm që ushtron së bashku disponueshmërinë e kredencialeve, gatishmërinë e rrjetit dhe rendin e njësive. Është gjithashtu testi që riprodhon dështimin e raportuar nga përdoruesi, të cilin një nisje manuale nuk e bën kurrë.

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

Rendi ka po aq rëndësi sa kredencialet. Një njësi që nis përpara se lidhja bazë e sipërme të konfigurohet do të dorëzohet, dhe disa shpërndarje ndryshojnë nëse presin lidhshmërinë. Nëse njësia raporton dështim në nisje por ka sukses kur niset me dorë tridhjetë sekonda më vonë, keni gjetur një problem rendi dhe jo një problem sekreti.

Verifikoni rrugët dhe DNS, jo vetëm ndërfaqen

Një ndërfaqe që ekziston nuk është tunel që funksionon. Pas një nisjeje pa mbikëqyrje, kontrolloni rrugët, gjendjen e zgjidhësit dhe një destinacion sipas adresës përpara se të kontrolloni një emër. Pastaj kontrolloni aplikacionin për të cilin ekziston tuneli.

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'

Nëse adresa funksionon dhe emri jo, problemi i mbetur është politika e DNS dhe jo tuneli. Shkruani cili pronar e nis shërbimin dhe ku jeton sekreti, sepse personi tjetër që do të rinisë këtë makinë do t'i ketë nevojë të dyja faktet.