VPN 사이트 확장: 게이트웨이 너머의 반환 경로를 따르십시오

지사의 트래픽은 도달하라는 요청을 받은 애플리케이션을 LAN에 포함하지 않은 게이트웨이에서 끝납니다. 서버는 두 번째 데이터 센터에 있으며, VPN이 한 번도 구성하지 않은 내부 링크 건너편에 있습니다. 가까운 게이트웨이에 프리픽스를 하나 더 추가해도, 먼 게이트웨이가 마지막 라우터가 아니라 암호화 종단점이기 때문에 그 경우에는 아무 효과가 없습니다. 경로에는 앞으로 가는 라우트, 먼 보안 경계에서의 수용, 그리고 목적지 자체 네트워크에서의 반환 결정이 필요합니다.

먼 게이트웨이는 암호화 종단점입니다

게이트웨이 간 IPsec은 두 보안 장치 사이의 트래픽을 보호하며, 내부 주소는 그 구간을 암호화된 채로 지나갑니다. 먼 게이트웨이 너머에서는 일반 라우팅이 맡으며, 데이터 센터 사이에 존재하는 모든 정책도 포함됩니다. 따라서 보호되는 구간은 여정의 일부이지 나머지가 아닙니다. 반대로 가정하는 것이 바로 건강한 터널과 도달할 수 없는 애플리케이션으로 설계가 끝나는 방식입니다.

경로를 세 부분, 즉 지사에서 가까운 게이트웨이로, 가까운 곳에서 먼 게이트웨이로, 먼 게이트웨이에서 애플리케이션으로 그리십시오. 각 부분에는 고유한 소유자와 고유한 고장 방식이 있습니다.

터널 정책의 양방향을 읽으십시오

터널 정책은 보통 로컬 측 관점에서 작성되며, 부분 구성은 바로 그 관행에서 나옵니다. 두 피어 모두 터널 내부에 나타날 지사의 소스와 목적지를 나열해야 하며, 설계가 의도하는 모든 변환도 포함해야 합니다. 가까운 쪽 끝만 업데이트하면 라우팅 장애처럼 보이는 두 번째 단계의 불일치가 생깁니다. 어떤 라우트든 건드리기 전에 두 정책 집합을 비교하십시오.

소스와 목적지를 사이트 이름이 아니라 주소로 쓰십시오. 여기의 모호성은 나중에 당혹스러운 비대칭으로 다시 나타납니다.

앞으로 가는 라우트를 추가하고 수용을 확인하십시오

먼 게이트웨이에는 애플리케이션 서브넷으로 가는 라우트가 필요하고, 그 사이의 모든 라우터는 지사 소스를 허용해야 합니다. 다이어그램이 주장하는 것이 아니라 먼 게이트웨이가 실제로 가진 것을 검증하십시오.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

일반 라우팅 테이블이 답할 수 없는 질문에 대해, 첫 번째 명령은 먼 게이트웨이가 해당 소스에 대해 선택할 송신 인터페이스와 다음 홉을 보고합니다. 추적은 패킷이 어디서 멈추는지 보여 주며, 먼 게이트웨이 이후의 단절은 터널이 아니라 내부 트랜짓을 가리킵니다. 예상치 못한 주소는 어딘가 계획되지 않은 곳에서 변환이 일어난다는 뜻이므로, 라우트가 있는데도 트래픽이 사라지면 먼 게이트웨이에서 캡처하고 도착하는 소스 주소를 읽으십시오. 여기의 모든 주소는 자리 표시자이므로 실제 지사, 트랜짓, 애플리케이션 서브넷으로 바꾸십시오.

지사에서 테스트한 다음 이전 경로를 다시 테스트하십시오

수용에는 먼 게이트웨이에서의 검사가 아니라 실제 소스가 필요합니다. 지사 호스트에서 검사를 실행하고 이전에 작동하던 목적지를 같은 테스트에 유지하십시오.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

애플리케이션의 응답은 앞으로 가는 경로와 돌아오는 경로를 함께 증명하며, 이전 목적지로의 ping은 변경이 이미 작동하던 것을 깨뜨리지 않았음을 증명합니다. 애플리케이션의 접근 규칙과 모든 반환 라우트가 그 값과 일치해야 하므로 애플리케이션이 기록하는 소스 주소를 확보하십시오. 지사가 터널 전에 변환하는 경우 정책 주소와 애플리케이션이 보는 주소는 설계상 다르므로 둘 다 기록하십시오. 이러한 경로는 한 번 검증되고 잊히기 쉬우므로 키 갱신이나 라우팅 변경 후 테스트를 반복하십시오.

세 구간 각각과 목적지 네트워크 내부의 반환 라우트에 소유자를 지정하십시오. 소유자가 네 명인 경로는 그들 사이의 틈에서 실패합니다.