ASA 사이트 간 VPN을 통해 내부 서비스 게시하기

사이트 간 VPN 뒤에 있는 서비스를 게시하는 일은 실패 지점이 다섯 개인 하나의 작업이며, 실패는 정해진 순서로 일어난다. 터널이 올라오고, 변환이 일치하고, 지사가 응답하며, 응답이 같은 경로로 돌아온다. 이 중 하나라도 틀리면 브라우저는 같은 것을 보여 주는데, 연결이 멈추거나 초기화될 뿐이다. 목록을 위에서 아래로 진행하고 처음 실패하는 점검에서 멈춘다.

점검 1: 터널이 원본 주소를 보호하는가

이미 트래픽이 통과하는 터널에서 시작한 뒤, 게시하려는 주소가 보호 범위 안에 있는지 확인한다. ASA에서 그 범위는 암호화 ACL이나 VTI의 경로에서 오며, 지사가 관리용으로 쓰는 서브넷이 아니라 원본의 실제 주소를 덮어야 한다. 원본을 놓치는 선택자는 터널은 올라와 있지만 흐름이 절대 들어가지 않는 상태를 만든다.

변환을 건드리기 전에 터널 카운터와 라우팅 테이블로 확인한다. 허브에서 터널을 거쳐 원본에 도달할 수 없다면 이 목록의 뒤쪽 어느 것도 그것을 고칠 수 없다.

보호 범위와 원본 주소가 맞지 않으면 여기서 멈춘다.

점검 2: 지사가 어떤 원본을 볼지 결정한다

지사는 클라이언트의 원래 주소를 보거나 변환된 주소를 보며, 그 선택이 돌아오는 경로를 결정한다. 클라이언트 주소를 보존하면 원본 로그에서 더 깔끔하게 읽히지만, 그러면 지사가 공인 클라이언트에 대한 응답을 터널로 되돌려 보내야 하는데, 일반적인 인터넷 기본 경로는 그것을 반대 방향으로 보내고 연결은 한 방향에서 죽는다. 원본을 지사가 이미 터널로 라우팅하는 주소로 변환하면 그 요구가 사라진다.

변환은 원본이 기록할 수 있는 것과 원본 기반 규칙이 일치할 수 있는 것도 바꾼다. 애플리케이션이 요청 뒤에 있는 사람을 알아야 한다면 그 자리는 인증된 리버스 프록시이며 NAT 결정이 아니다.

점검 3: 실제 인터페이스에 맞춰 변환을 작성한다

ASA는 변환 규칙을 순서대로 평가하고 어느 것이 일치했는지 보고하므로, 규칙 안의 인터페이스 쌍은 장식이 아니다. 바깥에서 안으로 가는 경로용으로 작성한 규칙은 가정한 입구와 출구가 다른 흐름에는 일치하지 않는다.

만들고 있는 경로에는 구간이 넷 있고, 넷 모두 일치해야 한다:

그 표의 범위는 자리 표시자로 다룬다. 중요한 것은 변환 후의 튜플이 지사가 터널을 통해 받아들이는 주소이고, NAT 상태에 역매핑이 있어 나갈 때 응답이 복원되는 것이다.

점검 4: 접근 규칙을 게시된 포트로 한정한다

호스트가 아니라 포트를 게시한다. 모든 서비스에서 원본을 허용하는 규칙은 게시된 애플리케이션 하나를 원본이 실행하는 모든 것에 이르는 경로로 바꾸며, 일부러 인터넷에서 빼 둔 관리 인터페이스까지 포함한다. 변환된 원본에서 원본으로 게시된 포트만 허용하고, 관리 서비스는 VPN 전용 경로에 남긴다.

동시에 규칙 순서를 확인한다. 구체적인 규칙 위에 넓은 허용이 있으면 구체적인 규칙은 보이지 않게 된다.

점검 5: 요청 하나와 그 응답을 추적한다

브라우저로 시작하지 않는다: 브라우저는 어느 구간이 실패했는지 감추기 때문이다. 허브에서 흐름을 추적하고 무엇이든 바꾸기 전에 결과를 읽는다.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

추적은 일치한 변환, 흐름을 허용하거나 거부한 접근 규칙, 패킷이 터널로 라우팅되었는지를 알려 준다. 예상하지 못한 인터페이스로 흐름이 나간다고 나오면 NAT 규칙의 인터페이스 쌍이 틀린 것이다. 거부가 나오면 규칙 순서가 틀린 것이다. 터널에는 도달하지만 원본이 응답하지 않는다면 문제는 지사의 돌아오는 경로다.

그다음 바깥에서 실제 요청을 하나 보내고 응답이 같은 터널로 돌아오는지 확인한다. 게시된 항목, 변환, 보호된 주소 쌍, 돌아오는 경로를 게시 기록으로 남긴다.