IOS VPN 출구에서 NAT의 안쪽과 바깥쪽 역할을 맡는 인터페이스

전체 터널 인터넷 출구를 제공하는 라우터는 하나처럼 보이는 두 가지 일을 합니다. 터널을 종료하고 복호화된 클라이언트 패킷을 인터넷으로 내보냅니다. 변환이 필요한 것은 두 번째 일뿐이며, 그 변환은 안쪽 흐름과 일치해야 합니다. 이 구분이 어떤 인터페이스가 NAT 역할을 맡고 규칙에 어떤 주소 범위가 나타나는지를 결정합니다.

패킷 하나를 라우터를 거쳐 따라가기

10.90.0.25 의 클라이언트가 공용 HTTPS 서비스를 여는 경우를 봅니다. 그 목적지가 터널에 들어오는지는 클라이언트 자체 정책의 결정입니다. 들어오면 라우터는 패킷을 복호화해 가상 인터페이스로 넘기고, 거기서 공용 업링크로 라우팅됩니다.

그 가상 인터페이스가 변환의 안쪽입니다. 공용 업링크가 바깥쪽입니다. 역할이 뒤바뀌거나 빠지면 패킷은 사설 출발지 그대로 나가거나 변환되기 전에 버려집니다.

변환 정책을 클라이언트 풀에 맞추기

NAT 규칙에는 클라이언트가 실제로 받는 범위를 적어야 하며, 우연히 같은 업링크를 공유하는 사무실 LAN이 아닙니다. 로컬 서브넷만 다루는 규칙은 둘 다 같은 인터페이스로 나가더라도 원격 클라이언트를 놓칩니다.

ip access-list extended NAT-TUNNEL
 permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overload

사설 사이트 예외는 따로 두고, 내부 목적지로 가는 트래픽은 원래 출발지를 유지해야 합니다. 그렇지 않으면 목적지는 도달할 수 없는 주소로 응답하고, 돌아오는 경로는 라우팅 루프처럼 보이는 방식으로 실패합니다.

역할은 배포된 설계의 실제 인터페이스에 적용합니다. 오래된 Easy VPN 답변에서 복사한 Virtual-Template 조각은 완전한 현재 구성이 아니며, 사용하는 터널 유형이 복호화된 패킷을 어느 인터페이스가 받는지를 결정합니다.

바깥 전송과 안쪽 변환을 분리하기

복호화된 애플리케이션 출발지를 변환하는 것은 IKE나 보호된 패킷을 상류의 NAT 장비로 통과시키는 것과 같은 작업이 아닙니다. 전자는 인터넷이 클라이언트 요청의 출발지로 무엇을 보는지를 바꾸고, 후자는 중간 상자를 거쳐 터널을 살려 둡니다.

둘을 혼동하면 전형적인 두 가지 장애가 생깁니다. 자기 터널 전송을 변환하는 라우터는 피어 관계를 깨고, 안쪽 흐름을 결코 변환하지 않는 라우터는 사설 주소를 인터넷으로 내보냅니다. 규칙을 고치기 전에 어느 흐름을 보고 있는지 읽고, 변경 뒤 터널이 살아 있는지 확인합니다. 탐색을 고치면서 터널을 떨어뜨리는 규칙은 문제를 해결한 것이 아니라 옮긴 것입니다.

두 장애 중 어느 것도 다른 하나를 바꿔서 고쳐지지 않습니다. 규칙을 고치기 전에 어느 흐름을 보고 있는지 읽습니다.

양쪽 경계에서 검증하기

인터넷 경계에서 애플리케이션 출발지를, 돌아오는 경로에서 복원된 목적지를 읽습니다. 전자는 변환이 일어났는지, 후자는 역방향 매핑이 올바른 클라이언트로 돌아왔는지를 알려 줍니다.

다음으로 승인된 분할 터널 경로를 쓰는 클라이언트를 시험합니다. 그 클라이언트는 이 라우터의 인터넷 변환을 전혀 거치지 않으므로 다르게 동작해야 하고, 그 차이가 트래픽이 어느 경로로 갔는지를 확인해 줍니다.

두 클라이언트가 똑같이 동작한다면 분할 터널 정책이 설계대로 움직이지 않는 것입니다. 쓰이지 않는 경로를 위해 쓴 규칙은 진짜 문제를 가리므로, 변환 규칙을 더 넣기 전에 그것을 고칩니다.