두 사이트, 하나의 서브넷: 각 사이트에 별칭 뷰를 구축하세요

두 고객 사이트가 모두 192.168.50.0/24를 사용하며, 원격 엔지니어가 각 사이트에서 같은 주소의 프린터에 접근해야 합니다. 어떤 라우팅 기법도 그 모호성을 혼자서 해결하지 못합니다. 각 사이트에는 서로 다른 주소 뷰가 필요하며, 게이트웨이는 무엇이든 전달하기 전에 그 뷰에서 사이트를 선택해야 합니다.

계획에는 네 부분이 있습니다: 별칭 접두사, 양방향 변환, 오버레이 정책, 이름입니다. 각 부분은 서로 일치해야 합니다.

사이트마다 별칭 접두사 하나를 선택하세요

각 사이트에 환경의 다른 누구에게도 속하지 않는 전체 별칭 접두사를 할당하세요. 두 사이트 계획에서는 사이트 A의 192.168.50.0/24를 172.21.10.0/24에, 사이트 B의 동일한 LAN을 172.21.20.0/24에 매핑할 수 있습니다. 클라우드 VPC와 다른 VPN 풀을 포함해 참여하는 모든 네트워크에 대해 후보를 확인하세요. 사설 주소 공간은 모든 조직이 공유하므로 범위가 RFC 1918이라는 사실은 여기서 비어 있다는 것을 말해 주지 않습니다.

원격 사용자에게는 원래 서브넷이 아니라 별칭을 게시하세요. 원래 범위는 로컬 사실로 남습니다.

양방향으로 변환하세요

양방향으로 변환하세요. 대상 매핑은 별칭 주소를 소유 사이트의 원래 주소로 다시 씁니다. 소스 매핑은 원격 호출자를 다른 사이트가 구별할 수 있는 별칭으로 다시 씁니다.

정적 일대일 매핑은 결정적이지만, 그렇다고 구현이 상태가 없는 것은 아닙니다. 역변환은 연결 상태에 의존할 수 있으며, 장애 조치나 비대칭 경로는 이를 무시하는 계획을 깨뜨릴 수 있습니다. 플랫폼 문서가 어느 경우가 해당하는지 결정합니다.

정책, 선택기, 경로가 적용되는 정확한 단계는 정책 기반 IPsec, 경로 기반 터널 및 기타 제품마다 다릅니다. 운영하는 제품에 맞춰 설계하세요.

계획을 오버레이를 통해 전달하세요

허브에서는 각 별칭 접두사를 그것을 소유한 사이트 경로에 할당하고 작업에 필요한 통과만 허용하세요. 메시에서는 관련된 모든 피어가 같은 접두사와 정책 지식을 필요로 합니다. 터널을 추가하는 것만으로는 모호한 주소 지정이 해결되지 않습니다.

전체 서브넷 게시는 단일 서비스 게시보다 넓습니다. 몇 대의 머신이나 포트만 필요하다면 액세스 규칙을 매핑보다 좁게 유지하세요.

헤더 변환은 애플리케이션 페이로드를 다시 쓰지 않습니다. 리디렉션, 구성 파일에 포함된 주소, 소스 기반 권한은 모두 여전히 원래 주소를 전달할 수 있습니다. ping만이 아니라 애플리케이션 경로를 테스트하세요. 작동하는 ICMP 응답은 매핑이 존재함을 증명할 뿐, 애플리케이션이 별칭을 받아들이는지는 말해 주지 않습니다.

각 호출자가 보는 이름을 수정하세요

유지보수 이름에 호출자의 뷰와 일치하는 답을 주세요. 원격 엔지니어가 호스트 이름을 확인하면 그 사이트의 별칭 주소를 반환해야 하며, 공유 원래 범위가 아닙니다.

첫 유지보수 창 전에 사이트별 DNS 뷰를 확인하세요. 원래 서브넷으로 확인되는 이름은 계획이 제거하려던 모호성으로 호출자를 되돌립니다.

사이트별로 기록하고 검증하세요

실제 호출자로부터 각 사이트를 개별적으로 수용하고 어느 머신이 응답했는지 확인하세요. 원래 주소, 별칭, 소유 게이트웨이, 허용된 서비스를 함께 기록하세요.

세 번째 사이트가 같은 기본 LAN으로 나타날 때 그 구분을 보존하는 것이 바로 이 목록입니다. 정책 기반 IPsec NAT 가이드는 하나의 구체적인 변환 모델을 문서화하지만, 모든 플랫폼에 대한 계약은 아닙니다.