VPN 서버에서 잠겨 나왔을 때: 두 번째 들어가는 길을 남겨 두세요

콘솔을 열고 방화벽 규칙 하나를 바꾸면 연결해 있던 터널이 사라집니다. 변경은 옳았지만 다시 불러오기는 그르았고, 이제 서버로 돌아가는 유일한 길은 방금 끊어 버린 그 길입니다. 두 번째 들어가는 길은 설계 결정이며, 장애가 터진 뒤가 아니라 그 전에 있어야 합니다.

아직 남아 있는 것을 점검하세요

눈앞의 콘솔 화면에서 시작해 터널에 의존하지 않는 경로를 나열하세요. 직렬 세션이나 VNC가 있는 공급자 웹 콘솔이 하나입니다. 별도 네트워크의 관리 인터페이스가 또 하나입니다. 물리적 접근이 세 번째이며, 사람들이 가장 나쁜 순간에 없다는 것을 알게 되는 경로입니다.

세 번째 열을 추상이 아니라 고장 목록으로 읽으세요. 그 경로 중 둘은 보통 같은 이유로 실패합니다. 이 표는 장애가 당신에게 설명해 주기 전에 그것을 알아차리는 방법입니다.

독립성은 의존성의 문제입니다

복구 계정은 비밀번호가 터널을 통해 닿는 서비스에 저장되어 있다면 독립적이지 않습니다. 같은 호스트, 같은 포트, 같은 방화벽 정책의 두 번째 VPN도 독립적이지 않습니다, 첫 번째를 끊은 변경이 둘 다를 끊기 때문입니다.

연쇄를 따라 내려가며 각 단계에 무엇이 필요한지 이름 붙이세요. 네트워크 도달성, 이름 해석, 인증 원천, 관리 서비스 자체가 서로 다른 네 가지 의존성이며, 그중 무엇이든 공유하는 경로는 그 고장을 물려받습니다.

한 번도 시험하지 않은 경로는 그 자체로 의심받아 마땅합니다. 몇 달째 열지 않은 콘솔은 이메일로 비밀번호 재설정을 요구할 수 있고, 그 사서함은 당신이 닿지 못하는 서버에 있을 수 있습니다. 모든 것이 돌아갈 때 경로를 시험하면 조용한 오후에 이것을 발견합니다.

통제된 변경 하나에는 두 번째 경로를 쓰세요

콘솔에서 스냅숏을 찍거나 편집하려는 구성을 복사하세요. 한 가지만 바꾸세요. 서비스를 다시 불러오고 다른 무엇이든 만지기 전에 결과를 읽으세요, 변경 두 개를 한꺼번에 하면 복구가 실험이 되기 때문입니다.

그 작업을 하는 동안 복구 세션은 열어 두세요. 두 번째 경로의 가치는 바꾸려는 바로 그 대상에서 살아남는다는 데 있으므로, 먼저 닫으면 그것을 쓸모 있게 만든 유일한 성질을 없애는 셈입니다.

기억이 아니라 복구 경로에서 확인하세요

중요한 점검은 정상 경로가 돌아오는지이며, 복구 세션은 그것을 순서대로 확인하는 자리입니다:

systemctl status openvpn-server@server --no-pager
ss -lntup | grep -E ':(1194|443)\b'
nft list ruleset | sed -n '1,40p'
journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30

먼저 서비스 상태, 다음으로 리스너, 다음으로 규칙, 마지막으로 저널을 읽으세요. 리스너 없이 도는 서비스는 서비스 구성을 가리키고, 닿을 수 있는 규칙이 없는 리스너는 필터링을 가리킵니다. 각 단계가 다음 단계를 좁히므로 순서가 중요하며, 저널로 건너뛰는 것은 대개 원인이 아니라 증상을 서술하는 오류를 읽는 일입니다.

systemctl 문서 는 여기서 쓰는 상태 및 재시작 동작을 다루며, 실패한 다시 불러오기가 이전 프로세스를 계속 실행하게 두는 방식도 포함합니다. 일관된 리비전을 되돌리는 것이 서버를 고칠 수 없는 클라이언트에서 거듭 접속하는 것보다 낫습니다. 변경 전에 정한 롤백 조건이 충족되었다면 복원하고 멈추세요.

목록을 최신으로 유지하세요

사람이나 인프라가 바뀌면 접근 목록을 검토하세요. 모든 것이 돌아갈 때 복구 경로를 시험하세요. 마지막 재편 이후 아무도 쓰지 않은 계정은 은퇴시키세요. 오래된 계정 둘과 만료된 인증서 하나는 화요일의 작은 정리이고 일요일의 장애입니다.

누가 각 경로를 쓸 수 있는지, 무엇을 허용하는지, 자격 증명을 어떻게 돌리는지 기록하세요. 소유자 없는 복구 경로는 잊힌 입구가 되며, 그것은 밖으로 잠기는 것과는 다른 종류의 고장입니다.