ASA: 하나의 공인 IP에서 VPN 포트와 DMZ 정적 PAT

서비스 둘, 공인 주소 하나, 그리고 포트를 예약하는 듯한 DNS 이름. 그렇지 않습니다. ASA에서 VPN 항목 옆에 DMZ 서버를 게시하기 전에 항목 튜플을 적고 순서대로 확인하십시오; 기존 서비스와 일치하는 첫 번째 필드가 계획이 멈추는 지점입니다. 아래의 모든 내용은 VPN이 내부 서버가 아니라 어플라이언스 자체에서 종료된다고 가정합니다.

명령을 쓰기 전에 다섯 개 필드를 적으십시오

모든 공인 항목에 대해 주소 패밀리, 공인 주소, 전송, 공인 포트, 소유자를 기록하십시오. 소유자는 ASA 로컬 서비스이거나 변환된 내부 서버입니다. 두 항목이 같은 주소를 공유하면서도 서로 다른 튜플일 수 있고, 두 항목이 다이어그램에서는 달라 보여도 어플라이언스에서는 충돌할 수 있습니다.

실제 포트, 즉 내부 서버가 실제로 수신하는 포트를 위한 두 번째 열을 두십시오. 공인 포트와 실제 포트는 독립적인 선택이며, 둘을 한 열로 합치는 순간 나중에 자신의 변환을 읽을 능력을 잃게 됩니다.

실제 위치와 매핑된 위치를 올바르게 읽기

추가하려는 서버가 아니라 이미 가진 튜플에서 시작하십시오. 예시적 분할은 승인된 VPN 항목을 공인 TCP 443에 두고 공인 TCP 8443에 DMZ HTTPS 서버를 게시하면서 그 서버는 443에서 계속 수신합니다:

Public TCP 443  -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443

배포된 명령에서 실제 서비스와 매핑된 서비스는 고정된 위치에 있으며, 둘을 뒤집으면 깨진 매핑이 아니라 다른 매핑을 뜻합니다. 작동하는 변환이 퍼즐이 되는 가장 흔한 방식입니다. 구성은 유효하며 그저 다른 곳을 가리킬 뿐입니다.

Cisco의 ASA 9.16 NAT 안내서는 정적 PAT, 인터페이스 주소 사용, 그리고 실제 포트와 매핑 포트의 의미를 문서화합니다. 실제로 실행하는 릴리스의 절을 읽으십시오. 오래된 플랫폼에서 기억한 명령은 완전한 현재 구성이 아닙니다.

전송을 예약의 일부로 계산하십시오

TCP 443과 UDP 443은 서로 다른 튜플이며, 그 차이가 UDP를 무료로 주지는 않습니다. VPN에 별도의 TLS 및 DTLS 리스너가 있을 수 있고, 다른 구성된 서비스가 원하는 전송을 이미 차지하고 있을 수도 있습니다. 웹 페이지가 VPN 항목 전부라고 가정하지 말고 유효한 리스너와 접근 정책을 목록화하십시오.

같은 주소로 확인되는 두 번째 호스트 이름도 전송 계층 충돌을 해결하지 않습니다. DNS는 이름-주소 매핑이며 포트 중개자가 아니고, PAT를 통해 서버를 게시하는 것은 VPN 리스너를 다른 포트로 옮기는 것과 같은 작업이 아닙니다.

VPN 항목이 정말로 이동해야 한다면 네 가지가 함께 바뀝니다. 클라이언트 프로필, 공인 URL, 업스트림 필터링, 그리고 배포가 사용하는 모든 전송입니다. 하나씩이 아니라 한 창에서 하십시오. 도달에 사용하는 서비스를 건드리기 전에 어플라이언스로 가는 별도 관리 경로를 열어 두십시오. 두 번째 경로가 없으면 그 이동은 외부에서 되돌릴 수 없는 변경입니다.

외부에서 새 연결로 검증하십시오

유효한 접근 정책 아래에서 의도한 DMZ 애플리케이션만 허용한 다음, 일치하는 변환 순서, 서버의 반환 경로, 인증서의 호스트 이름을 확인하십시오. PAT는 네트워크 목적지를 바꿀 뿐 애플리케이션 접근을 부여하지 않고 다른 호스트를 지목한 인증서를 고치지도 않습니다.

권한이 있는 외부 호스트에서 새 연결로 두 서비스를 모두 시험하십시오. VPN은 여전히 연결되어야 하고 DMZ 요청은 의도한 리스너에 도달해야 합니다. 이미 설정된 세션은 이전 상태를 유지할 수 있으므로 일 분 전에 바꾼 매핑에 대해 아무것도 증명하지 않습니다.

배포한 내용으로 항목 인벤토리를 갱신하여 주기를 닫으십시오. 만들지 않고 발견한 리스너도 포함하십시오. 그 주소에서 다음에 서비스를 게시할 사람은 당신의 표에서 시작하며, 그곳의 잘못된 행은 여기의 잘못된 명령보다 비쌉니다.