VPN 서버를 새 공용 IP로 옮기기: 먼저 무엇을 확인해야 하나

주소를 다시 할당하는 데는 일 분이 걸립니다. 문제가 터지는 곳은 그다음 주이며, 제공자 콘솔이 암시하는 위치와는 다를 때가 많습니다. 새 공용 IP는 네 군데에서 참조됩니다. 데몬이 대기하는 소켓, 클라이언트가 검증하는 신뢰 앵커, 옛 주소를 지정하는 모든 규칙, 그리고 이들을 묶는 DNS 레코드입니다. 두 이동은 제어판에서는 같아 보이지만 전혀 다르게 동작합니다. 운영 중인 머신에서 주소를 다시 할당하거나, 두 번째 엔드포인트를 세우고 클라이언트를 그쪽으로 옮기는 것입니다. 아래 점검은 값싼 실패를 먼저 두며, 각 절은 어느 이동에 적용되는지 밝힙니다.

제자리 교체와 병행 전환은 서로 다른 작업입니다

제자리 교체는 호스트, 키, 라우팅 테이블, 사용자 목록을 그대로 두고 주소만 바꿉니다. 부동 IP 재할당이 하는 일이 이것이며, 여러 제공자에서는 게스트가 전혀 알아차리지 못합니다. 변환이 인스턴스 앞에서 일어나기 때문입니다. 재구축이나 제공자에 의한 재할당은 더 거칩니다. 게스트가 변경을 보게 되고, 옛 값을 캐시한 모든 것이 같은 순간에 그것을 알게 됩니다.

병행 엔드포인트는 같은 일을 하는 두 번째 호스트입니다. 그것을 세우고 프로필 하나로 시험한 뒤, 새 것이 실제 경로에서 스스로를 증명할 때까지 옛 것을 응답하게 두십시오. 대가는 상태입니다. 피어 항목, 폐기, 로깅을 공유하지 않으면 우연히 이름만 공유하는 두 네트워크가 됩니다.

옛 주소가 적힌 모든 곳을 찾으십시오

텍스트 검색부터 시작하십시오. 설정 파일은 쉬운 절반입니다. 데몬 설정, 방화벽 조각, 모니터링 대상, 디스크에 생성된 클라이언트 번들을 검색하십시오. IPv6 주소를 게시한다면 그것도 포함하십시오. A 레코드만 따르는 이동은 이중 스택 클라이언트를 옛 경로에 남깁니다.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

그다음 커널을 훑으십시오. 실행 중인 시스템은 어떤 파일도 언급하지 않는 곳에 주소를 보관합니다. 정적 소스 NAT 규칙, ipset 항목, 바인드 주소, conntrack 항목은 그것들을 제거한 설정 변경보다 오래 살아남고, 일부는 저장된 규칙 집합에서 돌아왔기 때문에 재부팅도 견딥니다. 한 계층 위에서는 제공자의 보안 그룹, 로드 밸런서 대상, 모니터링 점검이 아예 파일 시스템에 없습니다.

무엇이든 바꾸기 전에 목록을 적으십시오. 롤백 스크립트로도 쓸 수 있습니다.

호스트 이름 클라이언트는 회복되지만 리터럴 IP 클라이언트는 조용해집니다

클라이언트가 호스트 이름으로 서버에 도달한다면 전환은 주로 DNS 문제이며, 어제 설정한 TTL이 얼마나 나빠질지를 결정합니다. 리졸버는 캐시하고, 스텁 리졸버는 또 캐시하며, 많은 클라이언트는 새 연결에서만 이름을 조회하므로 이미 맺어진 터널은 시작 주소를 유지합니다.

엔드포인트가 리터럴 주소라면 아무것도 다시 해석되지 않고 아무것도 불만을 기록하지 않습니다. WireGuard는 해석된 소켓 주소를 저장합니다. Endpoint = vpn.example.net:51820 는 wg-quick up 가 실행되는 순간 IP가 되고, 바꿀 때까지 그 IP로 남습니다. OpenVPN 은 더 관대합니다. 연결 시 remote 호스트 이름을 해석하고, resolv-retry infinite 가 있으면 다시 연결할 때 DNS를 다시 시도합니다. 리터럴 IP라면 둘 다 더 이상 존재하지 않는 머신에 계속 접속합니다.

사람들을 헷갈리게 하는 것은 거울상입니다. 이미 새 주소를 향한 클라이언트는 옛 리스너가 아직 응답하는 동안 자신의 책상에서 하는 모든 시험을 통과합니다. 나도 이것에 속았습니다. 새 엔드포인트는 휴대폰에서 한 번에 올라왔고, 낡은 프로필의 클라이언트는 옛 리스너를 훨씬 나중에 껐을 때에야 드러났습니다.

신뢰는 주소와 함께 움직이지 않습니다

WireGuard는 신원과 도달성을 분리하므로 주소 이동이 거의 무료입니다. 피어는 공개 키로 식별되고, 엔드포인트는 패킷이 지금 가는 곳일 뿐입니다. 호스트는 마지막으로 인증된 패킷의 출발 주소로 피어의 엔드포인트를 갱신합니다. 유휴 피어도 새 위치와 대화할 이유가 필요하며, 세션이 오래되어 핸드셰이크 재시도가 눈에 보이는 곳에서 실패할 때에야 주소를 배웁니다. WireGuard 빠른 시작 이 엔드포인트 필드를 다룹니다.

TLS 기반 서버는 반대의 경우입니다. 인증서는 이름에 묶여 있고, 주소로 접속하는 클라이언트는 자신이 접속한 대상을 주체 대체 이름과 비교합니다. DNS SAN만 가진 인증서에 IP로 접속하면 검증이 실패합니다. 클라이언트가 쓴 이름이 인증서에 없기 때문입니다. IP SAN으로 재발급하면 그 한 연결은 고쳐지지만 다음 이동은 더 나빠집니다. 프로필에 호스트 이름을 남기고 verify-x509-name 를 그대로 두면 아래 주소가 바뀌어도 검사는 엄격하게 유지됩니다.

그다음 데몬이 무엇에 묶여 있는지 확인하십시오. 옛 주소에 고정된 소켓은 조용히 실패합니다. local 203.0.113.10 로 시작한 OpenVPN 서버는 그 주소가 사라지면 올라오기를 거부하며, 0.0.0.0 에 있는 리스너는 변경을 무료로 따라갑니다. NAT도 같은 방식으로 갈립니다. MASQUERADE 는 머신이 지금 가진 주소를 따르고, 정적 SNAT --to-source 203.0.113.10 는 더 이상 소유하지 않은 주소로 계속 다시 씁니다. 그래서 돌아오는 트래픽이 사라집니다. 새 주소가 다른 업스트림 게이트웨이와 함께 온다면 rp_filter 를 확인하십시오. 역경로 필터링은 커널이 예상하지 않은 인터페이스로 도착한 돌아오는 트래픽을 버립니다.

전환 순서와 그것이 작동했다는 증거

TTL을 하루 전에 낮추고, 새 리스너를 세우고, 자신만 가진 프로필로 증명하십시오. 같은 네트워크 안에서 하는 시험은 거의 아무것도 증명하지 못하므로, 셀룰러의 휴대폰을 쓰고 엔드포인트로의 핑 대신 터널이 실어야 할 것을 시험하십시오.

창 전체에 걸쳐 두 주소를 지켜보십시오. 새 호스트의 wg show all latest-handshakes 또는 OpenVPN 상태 파일이 실제로 몇 개의 피어가 옮겨졌는지 알려줍니다. 새 엔드포인트에 예상한 피어가 있고 옛쪽에 뒤처진 것만 있다면, 옛 리스너를 은퇴시키고 낡은 NAT 규칙을 제거하며 제공자 방화벽에서 주소를 빼십시오. 옛 리스너를 제거하는 것이 건너뛰기 쉬운 단계이며, 낡은 프로필이 아직 옛 네트워크에 닿는 틈을 닫습니다.

시작 전에 롤백 방아쇠를 문서로 정하십시오. 합의한 창이 지난 뒤 새 엔드포인트가 실제 클라이언트 하나에서도 핸드셰이크를 받지 못하면 옛 주소를 복원하고 프로필 배포를 멈추십시오. 그 뒤 검색을 다시 돌려 은퇴한 주소에 묶인 리스너가 없는지 확인하십시오. 두 가지가 다음 이동으로 이어집니다. 클라이언트 프로필의 호스트 이름으로 다음 변경이 DNS 편집이 되게 하는 것, 그리고 서버 복구 노트 옆에 보관한 목록입니다.