Anypoint VPN 또는 Transit Gateway NAT: 번역은 어디서 하는가

NAT 요구 사항은 변경되는 주소와 그 주소를 변경할 수 있는 구성 요소를 명시하기 전까지는 요구 사항이 아닙니다. MuleSoft 연결에서 이 결정에는 세 가지 입력이 있습니다. 백엔드에 다대일 포트 변환이 필요한지 아니면 일대일 프리픽스 별칭이 필요한지, 실제로 소유한 AWS 연결이 그 매핑을 수행할 수 있는지, 그리고 전체 경로가 공급업체가 지원하는 조합 안에 머무는지입니다. 이것을 잘못하면 동작은 하지만 검토에서 떨어지는 랩을 만들게 됩니다.

한 가지 고정된 점은 Anypoint VPN 자체가 변환 장치가 아니라는 것입니다. CloudHub 2.0 문서는 NAT를 그곳에서 지원되지 않는 것으로 나열하므로, 터널이 워커 주소를 숨겨 줄 것이라고 가정하는 설계는 이미 깨져 있습니다.

번역이 무엇을 해야 하는지 정하십시오

많은 애플리케이션 워커가 백엔드에 하나의 주소로 보여야 한다면 요구 사항은 공유 소스 변환이며, 보통 직접 제어하는 방화벽의 상태 유지 SNAT 또는 PAT입니다. 그 요소는 승인된 경로에 있어야 하고, 흐름의 수명 내내 상태를 유지해야 하며, 다시 쓴 모든 연결의 반환 트래픽을 보아야 합니다. 세션 중간에 상태를 잃으면 연결이 저하되는 것이 아니라 종료됩니다. 변환 상태 공유를 거부하는 방화벽 쌍은 장애 조치 후 대기 구성원에 도착하는 모든 세션을 끊습니다. 그 요소의 크기는 처리량이 아니라 동시 흐름을 기준으로 산정하십시오.

반대로 두 네트워크가 겹치고 각 호스트에 별도의 별칭이 필요하다면 요구 사항은 모호하지 않은 매핑 프리픽스, 일치하는 경로, 매핑과 일치하는 이름 해석을 갖춘 일대일 주소 계획입니다. 모든 워커를 하나의 주소 뒤에 숨기는 것은 그 저렴한 버전이 아니며, 설계 검토에서 하나를 다른 것으로 바꾸는 것이 프로젝트가 분기를 잃는 방식입니다.

제품을 고르기 전에 결정을 구체적인 용어로 기록하십시오. 원래 소스, 원래 대상, 변환된 값, 시작 방향, 변환기 소유자, 예상 반환 경로입니다. 백엔드 로그가 어떤 식별자를 보존하는지도 추가하십시오. 모든 소스를 숨기는 설계는 클라이언트별 감사도 파괴하기 때문입니다.

AWS가 매핑을 대신 해 줄 수 있는지 확인하십시오

AWS는 이제 Transit Gateway 및 Cloud WAN 연결에서 관리형 일대일 NAT를 문서화하며, 이는 2026년 시월 말에 발표되었으므로 트랜짓 게이트웨이는 절대 변환할 수 없다는 오래된 일반 주장은 더 이상 유효하지 않습니다. Transit Gateway NAT 문서는 상태가 없는 IPv4 프리픽스 매핑을 설명합니다. 원래 프리픽스와 변환된 프리픽스는 같은 길이를 유지하고, 호스트 비트와 전송 포트는 변환을 거쳐도 남습니다. 인그레스와 이그레스 방향은 별개의 설계 결정으로 읽으십시오. 별도로 구성되며 하나가 준비되어도 다른 하나는 아닐 수 있습니다. 그 설명 어디에도 흐름별 상태가 암시되지 않으므로 매핑이 연결을 대신 추적해 주리라 기대하지 마십시오.

즉 10.80.0.0/16을 172.28.0.0/16에 매핑하면 10.80.10.23이 172.28.10.23이 됩니다. 이것은 /16을 하나의 주소로 접지 않으며 PAT 요구 사항을 대체하지도 않습니다. 또한 선택된 연결 유형을 포함하며 VPC와 Site-to-Site VPN이 그에 해당하지만 Client VPN 연결은 아닙니다. 구성은 Anypoint 쪽이 아니라 트랜짓 게이트웨이 소유자에게 있습니다.

이 기능을 또 하나의 가능한 제어 지점으로 다루고, 배포가 그것을 쓸 수 있다는 증거로 보지 마십시오. CloudHub 2.0은 고객 자신의 AWS 계정에 있는 트랜짓 게이트웨이로의 프라이빗 공간 연결을 지역 및 자격 조건과 함께 문서화하므로, 새 옵션을 중심으로 설계하기 전에 실제 연결 유형과 그 소유자, 공급업체의 지원 입장을 확인하십시오.

경로를 지원되는 경계 안에 유지하십시오

방화벽 변환기의 경우 동작하는 터널에 일반 NAT 규칙을 붙여 넣는 대신 해당 제품이 지원하는 VPN, 변환, 라우팅 모델을 사용하십시오. 백엔드의 응답은 같은 변환 요소를 통해 돌아와야 하며, 건강한 아웃바운드 터널은 그 반환 경로에 대해 아무것도 말해 주지 않습니다.

트랜짓 게이트웨이 경로의 경우 프라이빗 공간 연결, 관련 라우팅 테이블, 온프레미스 연결, 그리고 고객이 실제로 구성할 수 있는 부분을 목록화하십시오. 이것은 다른 연결 아키텍처이며 기존 Anypoint VPN 연결에 볼트로 고정한 NAT 체크박스가 아니고, 지원 경계도 그와 함께 이동합니다.

세 가지 옵션을 하나의 표에서 비교하십시오

대부분의 팀은 두 가지 질문에만 답하면 됩니다. 다대일인지 일대일인지, 그리고 연결의 소유자가 누구인지입니다. 아래 표는 그 답을 출발 옵션으로 바꿉니다.

세 번째 열은 나중에 덧붙이는 생각이 아니라 검토 질문으로 읽으십시오. 서류상 허용되지만 소유하지 않은 연결에 구성된 프리픽스 맵은 여전히 막힌 프로젝트이고, 트래픽은 통과시키지만 클라이언트별 로깅을 깨뜨리는 PAT 규칙은 뒤따르는 감사에서 실패합니다.

약속하기 전에 매핑을 검증하십시오

새 애플리케이션 작업 하나를 경로로 보내고 요청만이 아니라 응답도 확인하십시오. 백엔드 소유자에게 로그가 어떤 소스 주소를 기록했는지 물어보고, 주소 패밀리 처리가 양방향 모두 계획과 일치하는지 확인하고, 거부되어야 할 경로가 여전히 거부되는지 검증하십시오. 오래된 연결은 방금 바꾼 매핑에 대해 아무것도 증명하지 못합니다.

백엔드 인증은 어떤 변환된 주소가 허용 목록을 만족하는지와 무관하게 유지하십시오. 매핑은 네트워크 배관이지 접근 제어 결정이 아니기 때문입니다. 비밀번호 재설정이 NAT 프리픽스에 의존하는 순간, 앞으로의 모든 대역 변경이 장애가 됩니다.

승인 전에 세 가지 답을 적으십시오. 번역 유형, 변환기 소유자, 그리고 그것을 운반하는 지원되는 연결 또는 제품 경로입니다. 그중 하나라도 아직 추측이라면 설계는 변경 창에 대비되지 않은 것입니다.