Via VPN funkcias nur post saluto pro la ŝlosilringo

La komando funkcias, kiam vi estas salutinta, do vi metas ĝin en lanĉan skripton kaj iras hejmen. La sekvan matenon la maŝino estas interrete kaj la tunelo ne. La mito estas, ke funkcianta alvoko estas funkcianta servaĵo. Praktike la diferenco kutime estas unu el du aferoj: la profilo apartenas al via uzanta sesio anstataŭ al la sistemo, aŭ la sekreton malŝlosas io, kio ekzistas nur post kiam vi salutas. Ambaŭ perfekte funkcias en permana testo kaj malsukcesas ĝuste en la momento, kiam neniu rigardas.

Kial saluto igas ĝin funkcii

Grafika saluto startigas sesian buson kaj agenton de la sekreta servaĵo, kaj tie multaj labortablaj klientoj konservas la pasvorton de la profilo aŭ la pasfrazon de la privata ŝlosilo. Aktivigo, kiu post saluto ruliĝas kiel via uzanto, povas peti la sekreton de tiu agento kaj sukcesi. La sama aktivigo plenumita de lanĉa unuo havas neniun sesion, buson aŭ agenton, do la serĉo malsukcesas aŭ blokiĝas ĉe prompto, kiun neniu vidas.

Rulu la saman profilon antaŭ kaj post saluto kaj vi ricevas du malsamajn rezultojn el unu agordo. Tio estas la signo de dependeco de akreditaĵoj, ne de rompita tunelo, kaj ĝi klarigas, kial permana testo en terminalo pruvas malpli ol ĝi ŝajnas. La tunelo estas en ordo; mankas tio, kio malŝlosas ĝian sekreton.

Decidu, kiu posedanto startigas la tunelon

Estas du subtenataj ŝablonoj, kaj miksi ilin estas la alia maniero, kiel ĉi tio malsukcesas. NetworkManager povas aktivigi sistemampleksan konekton, kio taŭgas, kiam la maŝino jam centralizas sian retadon tie. Alternative, dediĉita systemd unuo rulas la VPN-on rekte kaj posedas la interfacon mem.

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

Ne rulu ambaŭ posedantojn kontraŭ unu agordo. Se NetworkManager administras la interfacon kaj unuo ankaŭ suprenigas ĝin, ili batalos pri vojoj kaj DNS, kaj la rezulta stato dependas de tio, kiu finiĝis laste.

Metu la sekreton tie, kie servaĵo povas legi ĝin

Fona servaĵo ne povas respondi al prompto. Sertifikataj pasfrazaj, kontaj pasvortoj kaj referencitaj aŭtentikigaj dosieroj ĉiuj bezonas aranĝon de konservado, kiun la unuo povas atingi sen homo, posedatan de la konto, kiu rulas la servaĵon, kaj nelegeblan por ĉiuj aliaj.

La tentiga fuĝvojo estas igi la dosieron legebla por ĉiuj, ĝis la permesa eraro malaperas. Tio interŝanĝas lanĉan malsukceson kontraŭ longdaŭra elmontro de akreditaĵoj, kaj ĝi estas la speco de ŝanĝo, al kiu neniu revenas. Uzu la mekanismon, kiun la disfaldiĝo jam fidas: limigitan akreditaĵan dosieron, neĉifritan ŝlosilon protektitan de dosieraj permesoj, aŭ sistemampleksan konekton kun sia propra sekreta konservejo.

Testu la eventon, kiu vere okazas

Mane startigi la servaĵon post saluto preskaŭ nenion testas. Restartigu, aŭ malŝaltu la grafikan saluton por unu ciklo, kaj observu la unuon leviĝi per si mem. Tio estas la sola testo, kiu samtempe ekzercas akreditaĵan disponeblon, retan pretecon kaj unuan ordon. Ĝi ankaŭ estas la testo, kiu reproduktas la malsukceson raportitan de la uzanto, kion mana starto neniam faras.

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

Ordo gravas same kiel akreditaĵoj. Unuo, kiu startas antaŭ ol la suba suprenligo estas agordita, rezignos, kaj iuj distribuaĵoj diferencas pri tio, ĉu ili atendas konekteblecon. Se la unuo raportas malsukceson ĉe lanĉo sed sukcesas, kiam ĝi estas mane startigita tridek sekundojn poste, vi trovis ordan problemon kaj ne sekretan problemon.

Kontrolu vojojn kaj DNS, ne nur la interfacon

Ekzistanta interfaco ne estas funkcianta tunelo. Post negardata starto, kontrolu la vojojn, la staton de la solvilo kaj unu celon laŭ adreso antaŭ ol kontroli nomon. Poste kontrolu la aplikaĵon, por kiu la tunelo ekzistas.

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'

Se la adreso funkcias kaj la nomo ne, la restanta problemo estas DNS-politiko kaj ne la tunelo. Notu, kiu posedanto startigas la servaĵon kaj kie loĝas la sekreto, ĉar la sekva persono, kiu restartigos ĉi tiun maŝinon, bezonos ambaŭ faktojn.