ISP를 바꿔도 사이트 VPN 주소를 다시 매기지 않는 방법

지사가 인터넷 사업자를 바꾸는데 파일 서버는 자기 주소를 그대로 유지합니다. 이 결과는 라우티드 사이트 VPN에서는 당연하고, 터널의 끝점 주소가 곧 애플리케이션의 주소라고 가정하는 사람에게는 뜻밖입니다. 둘은 설계의 서로 다른 계층에 있고, 움직인 것은 하나뿐입니다. 둘을 하나로 다루는 순간 사업자 이전이 주소 재할당 프로젝트가 됩니다.

독립적으로 움직이는 두 주소 계획

안쪽 계획은 애플리케이션이 쓰는 사설 주소를 설명합니다. 10.55.8.20 의 지사 서버, 그곳으로 라우팅되는 본사 프리픽스, 그리고 돌아오는 경로입니다. 바깥 계획은 두 게이트웨이가 서로에게 도달하는 방식을 설명합니다. 피어 주소, 수신 포트, 인터넷을 지나는 경로입니다.

사업자 변경은 바깥 계획을 건드립니다. 그 자체로 안쪽 계획의 변경을 요구하지는 않습니다.

두 대장을 분리해 두는 것이, 애플리케이션이 이미 자체적으로 트래픽을 암호화하는 경우에도 오버레이를 돌리는 실무적 이유입니다. 오버레이는 바깥의 변동을 견디는 안정된 안쪽 토폴로지를 줍니다. 애플리케이션은 주소와 방화벽 규칙, DNS 레코드를 유지합니다. 바뀌는 것은 전송 항목뿐이고, 그 검토는 훨씬 작습니다.

바깥 터널이 안쪽 대화를 나릅니다

게이트웨이 간 터널에서 바깥 IP 헤더는 두 게이트웨이를 주소로 삼습니다. 안쪽 헤더는 여전히 실제 애플리케이션 끝점을 가리킵니다. RFC 7296의 게이트웨이 간 설명은 이를 터널 끝점을 통해 트래픽을 전달하는 평범한 라우팅으로 다룹니다.

그래서 게이트웨이의 공인 주소가 바뀌어도 지사 서버는 10.55.8.20 을 유지할 수 있습니다. 안쪽 패킷에는 사업자 주소가 전혀 들어 있지 않습니다.

이 분리는 설계의 성질이지 자동 보장이 아닙니다. 대체 업링크가 지원되는 터널을 세우지 못하거나 안쪽 경로가 다시 설치되지 않으면, 주소가 그대로여도 애플리케이션은 경로를 잃습니다.

사업자 이전에는 여전히 점검 목록이 있습니다

바깥 점검 목록에는 다섯 항목이 있습니다. 피어 주소 또는 유지하는 이름, 수신 측과 상위 필터링, 경로상의 변환, 기대하는 피어 ID, 다른 게이트웨이에서 허용되는 설정입니다. 각각 따로 실패할 수 있습니다. 관리를 나르는 회선을 바꾸는 동안에는 별도의 복구 경로를 두십시오. 업링크 전환 중에 원격 접근을 끊는 것은 스스로 만든 장애입니다.

그다음 지사 프리픽스, 양방향 경로, 보호 정책, 그리고 실제 애플리케이션 흐름 하나를 확인합니다. 방금 인증된 터널은 옛 사설 서브넷을 가리키는 경로를 고쳐 주지 않습니다.

다른 연결된 사이트와의 주소 중복은 별도의 계획 문제입니다. 사업자 변경이 그것을 만들지는 않지만, 이전은 대개 그것이 드러나는 시점입니다.

남지 않는 것: 공인 출발지와 세션

안정된 사설 서버 주소는 안정된 공인 출발지가 아닙니다. 탐색이 새 사업자를 통해 직접 나가면 웹사이트는 새 사업자 쪽 주소를 봅니다.

그 주소를 안정적으로 유지하려면 자체 가용성과 정책을 갖춘 의도적인 출구 설계가 필요합니다. 터널에 무료로 딸려 오지 않습니다.

이미 맺어진 세션도 경로 변경을 견디지 못합니다. 터널은 몇 초 만에 다시 서도 옛 경로에 고정된 장시간 연결은 끊깁니다. 재접속이 허용되는 시간대에 전환을 계획하십시오. 특정 클라이언트와 그 타임아웃을 시험하지 않았다면 이전이 보이지 않을 것이라고 주장하지 마십시오.

네 가지 확인으로 이전을 검증합니다

변경 후 네 가지를 차례로 확인합니다. 터널이 의도한 피어와 서 있는지, 지사 프리픽스로 가는 안쪽 경로가 있는지, 정책이 애플리케이션 흐름을 허용하는지, 애플리케이션이 응답하는지입니다. 각각 고유한 명령이 있습니다.

Linux 게이트웨이에서는 이 세 가지가 그 목록의 중간을 덮습니다.

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

전송 주소는 한 대장에, 애플리케이션 주소는 다른 대장에 두십시오. 실제로 움직인 항목만 갱신합니다. 터널의 바깥 주소가 바뀌었다고 내부 의존 관계를 다시 매기는 일은 피할 수 있는 작업입니다.