사이트 간 VPN 내부의 NAT가 제자리를 얻는 때

두 사이트가 같은 사설 대역을 사용하고 터널은 올라오지만 그 안으로 유용한 것이 지나가지 않는다. 변환이 흔한 답이며 실제로 유효한 답이다. 먼 쪽에 다른 대역을 제시하면 겹침이나 다른 네트워크가 라우팅할 수 없는 반환 경로를 해결할 수 있다. 빠뜨리기 쉬운 부분은 변환이 이후의 모든 결정이 보는 주소를 바꾼다는 점이다. 이는 문서화된 설계 결정으로, 작성된 매핑과 함께 다루어야 하며 ping이 성공할 때까지 규칙을 덧붙이는 방식이 아니다.

어느 주소를 다시 쓸지 결정하라

출발지 변환은 원격 서비스와 그 로그가 클라이언트로 보는 것을 바꾸므로 지사 호스트는 도착할 때 게이트웨이 주소가 된다. 반면 목적지 변환이나 프리픽스 변환은 원격 자원에 대한 대체 주소를 제시한다. 일부 구축에서는 그렇지 않으면 동일한 두 네트워크를 분리하기 위해 양쪽에서 조정된 변환이 필요하며, 혼란의 대부분은 이 조합에서 시작된다.

변환 전의 출발지, 애플리케이션이 부르는 목적지, 그리고 각 게이트웨이가 일치시키는 주소 쌍을 적어라. 세 개의 열이면 충분하고, 세 번째 열이 바로 사람들이 빠뜨리는 열이다.

선택자의 순서도 중요하다. IPsec 정책의 선택과 변환은 정해진 단계에서 일어나므로 변환 전 주소를 위해 작성된 선택자는 가정한 단계에서 패킷과 결코 일치하지 않을 수 있다. 설치된 정책을 확인하라. 설치하려던 정책이 아니라, 한 구성 요소가 규칙을 받아들이고 다른 구성 요소가 무시할 때 둘이 정확히 갈라지기 때문이다:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

페이로드와 반환 경로를 따라가라

변환된 출발지를 개별 지사 호스트 대신 기록하는 서버는 원래 주소에 연결된 모든 규칙이나 보고서를 깨뜨린다. 매핑을 바꾸기 전에 그 필드로 하위 단계에서 결정을 내리는 것이 있는지 확인하라. 접근 목록, 감사 보고서, 속도 제한, 라이선스 검사 등이다. 각각은 변환이 나중에 설명되지 않는 장애로 드러나는 지점이다.

페이로드 안에 주소를 담는 프로토콜은 별도의 계획이 필요하다. 바깥 헤더를 다시 써도 안쪽 참조에는 손대지 않기 때문이다. 액티브 FTP, SIP, 일부 원격 접속 제품이 고전적인 사례이며, 이를 무시한 설계는 웹 트래픽에서는 동작하고 중요했던 애플리케이션에서는 실패한다.

반환 트래픽은 상태 기반 매핑에 의존한다. 게이트웨이 페일오버는 그 상태를 잃을 수 있고, 비대칭 라우팅은 이를 우회할 수 있으며, 재시작은 먼 쪽에서 세션이 열린 채로 상태를 지울 수 있다. 그래서 목적지에 도달하는 요청과 완료되는 세션은 서로 다른 두 가지 수용 결과다.

사이트 재번호 부여와 견주어 보라

충돌하는 한 사이트를 재번호 부여하면 매핑이 완전히 사라지고 변환 표 없이 읽을 수 있는 주소 계획이 남는다. 운영 비용은 비싸다. DNS 레코드, 정적 할당, 방화벽 규칙, 문서화된 모든 주소가 함께 바뀌어야 한다. 비용은 계획된 창에서 한 번 발생하며 최종 상태가 분명하다. 대신 얻는 것은 몇 년 뒤에도 조회 표 없이 패킷 캡처를 읽는 능력이다.

변환은 대부분의 로컬 변경을 피하고 DNS, 문서, 문제 해결에서 영원히 유지해야 하는 매핑을 만든다. 비용은 터널 안에서 하나의 프리픽스가 다른 의미를 가진다는 것을 배워야 하는 모든 미래의 엔지니어 형태로 계속 발생한다.

임시 연결이나 통제하지 않는 파트너 네트워크라면 지속 비용은 보통 지불할 가치가 있다. 소유하고 있으며 앞으로 수년간 소유할 두 사이트라면 마이그레이션을 정직하게 계산했을 때 재번호 부여가 더 저렴한 결정인 경우가 많다.

실제 세션으로 양방향을 입증하라

단일 프로브가 아니라 애플리케이션 세션을 시험하라. 성공한 에코 요청은 한 프로토콜의 한 방향이 동작함을 증명할 뿐이며, 상태가 있는 모든 것에 실패하는 반환 경로와 완전히 양립한다. 설계를 촉발한 서비스를 사용하고, 먼 쪽의 로그를 읽어 어떤 출발지 주소가 기록되었는지 확인하라.

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

그다음 매핑을 통해 의도한 서비스만 도달 가능한지 확인하라. 변환은 주소 지정을 바꿀 뿐 권한 부여에는 아무것도 하지 않으므로 무엇이 허용되는지는 여전히 방화벽 정책이 결정한다. 불분명한 변환 프리픽스를 접근 제어로 삼는 설계에는 접근 제어가 전혀 없다.

매핑, 시험한 세션, 양쪽이 관찰한 주소를 기록하라. 이 터널을 다음에 디버깅할 사람에게는 구성 파일보다 그 세 가지 사실이 더 필요하다.