VPN이 로그인 후에만 작동하는 이유는 키링 때문입니다

로그인한 상태에서는 명령이 작동하므로 시작 스크립트에 넣고 집에 갑니다. 다음 날 아침 기기는 온라인인데 터널은 아닙니다. 작동하는 호출이 곧 작동하는 서비스라는 것은 신화입니다. 실제 차이는 보통 두 가지 중 하나입니다. 프로필이 시스템이 아니라 사용자 세션에 속해 있거나, 비밀이 로그인 후에만 존재하는 무언가로 잠금 해제된다는 것입니다. 둘 다 수동 테스트에서는 완벽하게 작동하고 아무도 보지 않는 바로 그 순간에 실패합니다.

로그인이 작동하게 만드는 이유

그래픽 로그인은 세션 버스와 비밀 서비스 에이전트를 시작합니다. 많은 데스크톱 지향 클라이언트가 프로필의 비밀번호나 개인 키 암호 문구를 바로 거기에 보관합니다. 로그인 후 사용자로 실행되는 활성화는 그 에이전트에 비밀을 요청해 성공할 수 있습니다. 부팅 시점 유닛이 실행하는 같은 활성화에는 세션도 버스도 에이전트도 없으므로 조회가 실패하거나 아무도 보지 못하는 프롬프트에서 멈춥니다.

같은 프로필을 로그인 전후로 실행하면 하나의 구성에서 두 가지 다른 결과를 얻습니다. 이것은 깨진 터널이 아니라 자격 증명 의존성의 서명이며, 터미널의 수동 테스트가 보이는 것보다 적게 증명하는 이유를 설명합니다. 터널은 괜찮습니다. 그 비밀을 여는 것이 빠져 있습니다.

터널을 시작할 소유자를 정하십시오

지원되는 패턴은 두 가지이며, 둘을 섞는 것이 이것이 실패하는 또 다른 길입니다. NetworkManager는 시스템 범위 연결을 활성화할 수 있는데, 기기가 이미 네트워크를 그곳에 집중시키고 있을 때 적절합니다. 또는 전용 systemd 유닛이 VPN을 직접 실행하고 인터페이스를 스스로 소유합니다.

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

하나의 구성에 두 소유자를 함께 실행하지 마십시오. NetworkManager가 인터페이스를 관리하고 유닛도 그것을 올리면, 둘은 경로와 DNS를 두고 다투게 되며 결과 상태는 누가 마지막에 끝났는지에 달려 있습니다.

서비스가 읽을 수 있는 곳에 비밀을 두십시오

백그라운드 서비스는 프롬프트에 답할 수 없습니다. 인증서 암호 문구, 계정 비밀번호, 참조된 인증 파일은 모두 유닛이 사람 없이 접근할 수 있고, 서비스를 실행하는 계정이 소유하며, 다른 누구도 읽을 수 없는 저장 방식이 필요합니다.

유혹적인 지름길은 권한 오류가 사라질 때까지 파일을 모든 사람이 읽을 수 있게 만드는 것입니다. 그것은 시작 실패를 장기적인 자격 증명 노출과 맞바꾸는 것이며, 아무도 다시 들여다보지 않는 종류의 변경입니다. 배포가 이미 신뢰하는 메커니즘을 사용하십시오. 제한된 자격 증명 파일, 파일 권한으로 보호되는 암호화되지 않은 키, 또는 자체 비밀 저장소를 가진 시스템 범위 연결입니다.

실제로 일어나는 이벤트를 시험하십시오

로그인 후 서비스를 수동으로 시작하는 것은 거의 아무것도 시험하지 않습니다. 재부팅하거나 한 주기 동안 그래픽 로그인을 비활성화하고 유닛이 스스로 올라오는지 지켜보십시오. 자격 증명 가용성, 네트워크 준비 상태, 유닛 순서를 함께 시험하는 유일한 테스트입니다. 또한 사용자가 보고한 실패를 재현하는 테스트이기도 하며, 수동 시작은 결코 그렇게 하지 못합니다.

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

순서는 자격 증명만큼 중요합니다. 기반 업링크가 구성되기 전에 시작하는 유닛은 포기하며, 연결성을 기다리는지는 배포판마다 다릅니다. 유닛이 부팅 시 실패를 보고하지만 삼십 초 후 손으로 시작하면 성공한다면, 비밀 문제가 아니라 순서 문제를 찾은 것입니다.

인터페이스만이 아니라 경로와 DNS를 검증하십시오

존재하는 인터페이스는 작동하는 터널이 아닙니다. 무인 시작 후에는 이름을 확인하기 전에 경로, 리졸버 상태, 주소로 특정한 목적지 하나를 확인하십시오. 그다음 터널이 존재하는 이유인 애플리케이션을 확인하십시오.

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'

주소는 작동하고 이름이 작동하지 않는다면 남은 문제는 터널이 아니라 DNS 정책입니다. 어느 소유자가 서비스를 시작하고 비밀이 어디에 있는지 기록하십시오. 이 기기를 다음에 재부팅할 사람에게는 두 사실이 모두 필요합니다.