재부팅 후 SSH가 수신하지 않음: VPN 주소가 늦게 도착

설정 중에 SSH를 터널 주소에 바인딩하면 작동하지만, 다음 재부팅 후에는 누군가 서비스를 수동으로 다시 시작할 때까지 아무도 로그인할 수 없다. 자격 증명이 문제가 아니다. 데몬은 아직 존재하지 않는 주소를 커널에 요청했고 바인딩이 실패했으며, 그 메시지는 부팅 로그를 지나쳐 갔다. 인증 문제처럼 보이는 것은 시작 순서 문제다.

바인딩 오류가 실제로 말하는 것

수신 소켓은 그 순간에 존재하는 주소에 만들어져야 한다. VPN 인터페이스가 나중에 나타나면, 터널 주소에만 바인딩하도록 구성된 데몬은 붙을 대상이 없다. 구성은 구문상 유효하게 남지만, 환경이 그저 준비되지 않았을 뿐이다. 수동 시작 이후 계속 실행 중인 서비스는 부팅 경로를 결코 거치지 않으며, 그래서 결함은 다음 재시작에서만 나타난다. 바인딩 실패 시각과 주소 할당 시각을 비교하면 순서는 분명해진다.

구성의 유효성과 런타임 준비 상태는 별개의 속성이며, 둘 다 시험해야 한다. 둘 중 하나는 아무 말 없이 실패하기 때문이다.

어느 프로세스가 포트를 소유하는가

데몬이 항상 리스너를 만드는 구성 요소는 아니다. 소켓 활성화는 그 책임을 유닛으로 옮기며, 그러면 데몬을 다시 시작해도 아무것도 바뀌지 않는다.

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

소켓 목록은 어느 프로세스가 어느 주소에서 포트를 잡고 있는지 보여 주고, 유닛 덤프는 소켓 유닛이 아예 있는지 보여 준다. 활성화가 개입하면 주소는 소켓 유닛에 속하며 데몬 파일은 권위가 없다. 증상에서 추론하지 말고 실제 바인딩 오류를 부팅 로그에서 읽어라. 소켓 유닛이 없다는 것은 데몬이 직접 바인딩하는 고전적 배치를 뜻할 뿐이다.

준비 상태를 명시하라, 잠이 아니라

고정 지연은 빠른 하드웨어와 느린 네트워크를 동일하게 취급하는 추측이다. 대신 의존 관계를 표현하여 주소를 기다린 다음 시작하라.

ip -4 addr show dev tun0
systemctl edit ssh.service

주소가 나타날 때까지 반복하는 ExecStartPre 명령을 추가하거나, 인터페이스를 소유한 특정 네트워크 타깃 뒤에 유닛을 배치하라. 두 방식 모두 다음 관리자가 읽을 수 있는 곳에 의존 관계를 기록한다. 루프에는 타임아웃이 필요하며, 그렇지 않으면 실패한 VPN이 오류를 보고하는 대신 멈춘 유닛을 남긴다. 그런 다음 일반 인터페이스는 필터 규칙의 관리 아래에 둔 채 데몬이 터널 주소에 바인딩하는지 확인하라.

깨끗한 부팅과 재연결 시험

모든 것이 온라인 된 후의 수동 재시작은 부팅 순서에 대해 아무것도 증명하지 않는다. 터널이 자동으로 올라오도록 구성한 상태에서 머신을 재부팅하고 개입 없이 리스너가 나타나는지 관찰하라.

systemctl status ssh.service
ss -ltnp 'sport = :22'

재연결은 주소를 바꿀 수 있고 하드코딩된 바인딩은 그것을 따르지 않으므로 터널을 끊고 다시 설정하라. 테스트 중에는 대역 외 복구 경로를 유지하여 잘못된 순서 변경으로 호스트에서 잠기지 않도록 하라.

성공 기준은 문서화된 의존 관계 아래에 나타나는 리스너이지, 누군가 다시 시작하는 것을 기억한 리스너가 아니다.