접근 권한을 남기지 않고 VPN 서버를 폐기하는 방법

폐기 티켓이 열리는 날에도 클라이언트는 여전히 연결합니다. 앱에는 프로필이 남아 협상을 하고, 아무것도 바뀌지 않은 것처럼 터널이 올라옵니다. 바로 이 순간에 서비스를 구축한 방향과 반대로 작업해야 합니다. 클라이언트 목록에서 시작해 바깥의 리스너로, 다음으로 방화벽으로 나아가고, 마지막으로 그 모두보다 오래 사는 자격 증명으로 끝냅니다. VM 종료는 첫 단계가 아니라 마지막 단계이며, 이 절차는 호스트에 대한 콘솔 접근과 클라이언트 레코드 및 DNS를 편집할 권한이 있다고 가정합니다.

먼저 클라이언트 목록을 훑으세요

프로필을 배포하는 무엇이든 열고, 서버를 만지기 전에 각 항목이 휴대폰, 노트북, 지점 라우터, 매일 밤 동기화하는 컨테이너처럼 접근 권한이 있다고 믿는 기기인 목록을 읽으세요. 그 목록을 티켓으로 내보내세요. 호스트가 사라진 뒤에는 누가 연결되어 있었는지 알려 줄 wg show 이 없습니다.

각 기기를 대체 엔드포인트, 더 이상 필요 없음, 알 수 없음으로 분류하되, 중요한 것은 알 수 없음 바구니입니다. 몇 달 뒤 누군가 서랍에서 찾아 시도할 프로필이 바로 그것들이기 때문입니다. 접근 요청에 쓰는 것과 같은 채널로 공지를 보내고, 이전 엔드포인트가 응답을 멈출 날짜를 적으세요.

파일이 아니라 신원을 폐기하세요

폐기라고 불리는 두 가지 다른 작업이 있습니다. WireGuard에서 피어는 AllowedIPs 항목이 있는 피어 섹션에 나타나는 공개 키로만 승인되므로 노트북에서 구성 파일을 지워도 서버에서는 아무것도 바뀌지 않습니다. 유지하는 피어를 떨어뜨리지 않고 피어 블록을 제거하고 파일을 다시 적용하는 방법은 wg(8) 매뉴얼이 설명하는 대로입니다:

wg show
wg set wg0 peer <CLIENT_PUBLIC_KEY> remove
wg syncconf wg0 <(wg-quick strip wg0)

wg syncconf 은 유지보수 창을 아껴 주는 부분입니다. 파일에서 인터페이스를 그 자리에서 다시 만들기 때문에 피어 하나를 제거해도 다른 모두가 쓰는 터널이 무너지지 않습니다. 피어 하나가 아니라 호스트 전체를 폐기하더라도 그 키를 다른 곳에서 신뢰할 수 있기 때문에 순서는 여전히 중요합니다.

X.509 구성에서는 폐기 단계가 파일이 아니라 인증서이므로, openssl ca -revoke client.crt 을 실행하고 이어서 openssl ca -gencrl -out crl.pem 을 실행합니다. 효과는 검증자가 그것을 읽는 곳에서만 나타나며, 즉 OpenVPN 서버에 crl-verify 이 구성되고 그 뒤에 다시 로드된 경우입니다. 이 게이트웨이가 그 CA의 유일한 소비자라면 CRL은 그것이 죽는 날 의미를 잃지만, 같은 CA가 두 번째 게이트웨이에 서명한다면 한 번도 폐기하지 않은 인증서가 거기서 계속 작동합니다.

계정은 세 번째 경우이며 가장 자주 빠뜨리는 경우입니다. 게이트웨이가 RADIUS, LDAP 또는 호스팅 ID 공급자에 대해 인증했다면 계정은 VPN 밖에 있습니다. 디렉터리에서 비활성화하세요. 서버에서 사용자 스탠자를 삭제해도 유효한 자격 증명이 남아, 대체 엔드포인트가 같은 디렉터리를 가리키는 순간 그것을 받아들입니다.

리스너와 그곳으로 가는 경로를 닫으세요

재부팅에도 살아남는 방식으로 서비스를 중지하고, 유닛 상태가 아니라 소켓 목록으로 확인하세요. systemctl disable --now wg-quick@wg0 은 인터페이스를 멈추고 wg-quick이 추가한 경로와 규칙을 제거합니다. systemctl disable --now openvpn-server@server 은 템플릿 OpenVPN 인스턴스에 같은 일을 합니다. 둘 중 하나 뒤에 ss -lunp 과 ss -ltnp 을 실행하고, 이전 포트에 대한 빈 결과만이 의미 있는 증거입니다.

wg-quick이 추가한 것은 wg-quick이 제거하지만, 직접 추가한 것은 남습니다. 영구 NAT 규칙, 방화벽 허용, 라우터 포트 포워딩, 클라우드 보안 그룹 인그레스 규칙, 로드 밸런서 리스너입니다. 이것들은 명시적으로 제거해야 하며, DNS 레코드, 즉 이름을 가리키는 A, AAAA, 모든 CNAME도 마찬가지입니다. 죽은 호스트로 확인되는 이름은 확인되지 않는 이름과 다르게 실패하며, 그 차이는 누군가의 오후를 앗아갑니다.

잊고 있는 사본이 바로 클론입니다. 백업에서 복원한 스냅숏이나 VM은 호스트 키와 이전 피어 목록을 여전히 보관하며, 무언가가 그것을 같은 주소로 되돌리면 클라이언트는 폐기했다고 믿는 서비스에 다시 연결합니다. 백업 세트를 폐기된 서비스에 속한 것으로 라벨링하고 자동 복원 경로에서 빼두세요.

여전히 이전 엔드포인트를 가리키는 것을 추적하세요

캐시된 프로필은 DNS보다 오래 살아남습니다. 숫자 주소가 있는 저장된 구성은 레코드가 사라진 뒤에도 계속 연결을 시도하며, 항상 켜져 있는 클라이언트는 네트워크가 바뀔 때마다 다시 시도합니다. 리스너가 닫혀 있으므로 그것은 접근이 아니라 잡음이지만, 둘 중 무엇을 보고 있는지 아는 것이 티켓에 어떻게 답할지를 결정합니다.

다음으로 포트를 더듬는 가동 시간 점검, 호스트에서 구성을 가져가던 백업 작업, 피어 항목을 밀어 넣는 데 쓰인 자동화 자격 증명, 이 엔드포인트만을 위해 만든 복구 계정 등 아무도 VPN 아래에 보관하지 않는 의존성을 쓸어내세요. 각각은 고유한 수명과 소유자를 가진 접근 경로이므로, 조용히 삭제하는 대신 각각 결정을 내립니다.

확인한 다음 기록하세요

외부에서 한 테스트가 예상대로 실패할 때 폐기가 끝납니다. 통제하지 않는 네트워크에서 이전 주소와 포트에 연결하세요. 필터되거나 거부된 결과가 성공 사례입니다. 클라이언트 앱에서 프로필이 꺼진 것이 아니라 제거되었는지, 관리 프로필이 조용히 다시 추가하지 않는지 확인하세요.

다음으로 엔드포인트, 날짜, 폐기한 키와 인증서, 비활성화한 계정, 백업이 있는 위치 등 무엇을 했는지 기록하세요. 나중에 이전 구성을 발견한 사람은 추측 없이 폐기되었는지 아니면 그저 삭제되었는지 답할 수 있어야 하며, 티켓의 짧은 표가 그것을 가능하게 합니다.

티켓을 닫기 전에:

• 클라이언트 프로필을 제거하거나 교체했고, 알 수 없는 기기를 해결했습니다
• 피어를 제거하고 구성을 다시 적용했거나, 인증서를 폐기하고 CRL을 게시했습니다
• 디렉터리 계정을 비활성화했고, 로컬 파일만 삭제하지 않았습니다
• 서비스를 비활성화했고, 이전 포트에 리스너가 남아 있지 않습니다
• 방화벽, 포트 포워딩, 보안 그룹, DNS 항목을 제거했습니다
• 백업에 라벨을 붙였고, 스냅숏을 복원 경로에서 제외했습니다
• 모니터링 및 자동화 자격 증명을 폐기했습니다

대체 서비스를 별도로 확인하세요, 한 번도 이전 프로필을 가진 적 없는 클라이언트에서. 그 한 번의 테스트가 서비스를 폐기한 것인지 문제의 이름만 바꾼 것인지 알려 줍니다.