이중 WAN VPN 정책은 어떤 패킷과 일치해야 하는가?

VPN을 두 번째 업링크로 라우팅하라는 요청은 적어도 두 가지 서로 다른 작업을 가리키며, 하나를 고치는 정책은 다른 하나를 건드리지 않습니다. 첫 번째 작업에서 두 끝점 사이의 암호화된 전송은 다른 WAN 주소로 옮겨갑니다. 두 번째에서는 연결된 사용자의 복호화된 애플리케이션 흐름이 다른 다음 홉으로 나갑니다. 둘 다 정당하고 둘 다 라우팅을 사용하며, 각각은 결정이 내려지는 지점에 존재하는 패킷에 대한 일치를 필요로 합니다. 첫 번째 확인이 이후 규칙이 어떤 패킷을 지목해야 하는지를 정하므로, 아래 확인을 순서대로 진행하십시오.

두 대화에 이름을 붙이기

사무실 게이트웨이에 연결된 원격 근무자가 내부 애플리케이션 서버로 HTTPS를 여는 상황을 생각해 보십시오. 회선 위에는 두 개의 독립적인 대화가 있고, 양 끝에서 서로 다른 주소를 가집니다. 바깥 대화는 게이트웨이 주소에서 피어 주소로, 구축이 협상한 프로토콜과 포트를 써서 두 VPN 끝점 사이에서 흐릅니다. 안쪽 대화는 클라이언트에 부여된 주소에서 포트 443의 애플리케이션 서버 주소로 흐릅니다.

애플리케이션의 목적지 포트는 VPN의 전송 포트가 아니며, TCP 443에 아무리 많은 정책을 걸어도 터널은 움직이지 않습니다. 마찬가지로 피어의 전송 주소를 리디렉션하는 규칙은 그 사용자의 HTTP 요청이 복호화 후 어디로 가는지에 대해 아무 말도 하지 않습니다. 이 분야의 혼란 대부분은 하나는 이름 붙이고 다른 하나는 설정하는 데서 오므로, 규칙을 건드리기 전에 두 대화를 실제 주소와 함께 적어 두십시오.

정책이 패킷을 실제로 볼 수 있는 곳 찾기

일치는 패킷이 아직 설명한 형태로 남아 있는 체인과 네임스페이스에서 평가되어야 합니다. LAN 인그레스에 붙은 규칙은 안쪽 패킷을 암호화되지 않은 채로, 터널로 라우팅되기 전에 봅니다. 로컬에서 생성된 트래픽에 적용한 규칙은 게이트웨이 자체가 만드는 패킷을 봅니다그러나 게이트웨이가 단순히 전달하는 트래픽을 자동으로 포함하지는 않습니다. 캡슐화된 출력은 다시 세 번째 경우이며, 보통 LAN 쪽이 아니라 터널을 나르는 인터페이스에서 처리합니다.

같은 설정 조각이 두 플랫폼에서 다르게 동작하는 이유는 연결 지점이 다르고 공급업체의 정책 훅이 암호화 단계 앞이나 뒤에 놓일 수 있기 때문입니다. 다른 공급업체의 다이어그램에서 순서를 가정하지 말고 해당 제품의 패킷 경로를 읽으십시오.

협상한 전송 확인하기

UDP로 캡슐화한 IPsec의 경우, RFC 3948은 ESP를 UDP 안에 넣고 공유 포트에서 IKE를 구별할 수 있도록 비 ESP 표식을 사용합니다. 순수 ESP는 IP 프로토콜이며 TCP나 UDP 포트가 아니므로, 포트 번호로 작성한 방화벽 규칙은 전혀 일치하지 않습니다. 이 구분이 WAN 정책에 UDP 규칙이 필요한지, 프로토콜 규칙이 필요한지, 아니면 둘 다인지를 결정합니다.

협상된 값이 기억한 값보다 우선합니다. 만일을 대비해 TCP 4500이나 오래된 공급업체 포트를 추가하면 무관한 트래픽을 잡고 실제 분류 문제를 가리므로, 장비에서 연결의 현재 포트와 주소를 읽으십시오.

약속하기 전에 반환 경로 확인하기

나가는 방향의 성공은 설계의 절반만 증명합니다. 원격 클라이언트 풀 쪽으로 돌아오는 패킷은 캡슐화가 자리를 대신하는 순간 클라이언트 주소 아래에서 더는 보이지 않으며, 바깥 목적지는 피어의 전송 주소입니다. 두 번째 업링크가 다른 사업자를 통해 그 피어에 도달한다면, 그 변환과 필터링이 첫 번째와 어긋날 수 있고, 연결은 마이그레이션 대신 다시 구축해야 할 수도 있습니다.

네트워크 주소 변환 상태는 WAN 전환의 흔한 희생물입니다. 선택한 업링크, 예상되는 바깥 출발지 주소, 사용 중인 변환, 피어에서 그쪽으로의 도달 가능성을 기록한 뒤, 전송이 나르는 터널로 보내지 않으면서 도달 가능하게 유지하십시오.

두 번의 캡처로 두 계층 모두 확인하기

WAN 인터페이스에서 한 번, 터널 안에서 한 번 캡처하면 어떤 설정 비교보다 빨리 문제를 정리합니다. 승인된 클라이언트가 요청 하나를 수행하는 동안 게이트웨이에서 실행하고 두 파일을 모두 보관하십시오.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

첫 번째 캡처는 바깥 대화가 의도한 인터페이스를 예상한 출발지 주소로 떠나는 모습을 보여야 합니다. 두 번째는 안쪽 대화가 중복 없이 한 번만, 클라이언트 주소를 출발지로 애플리케이션 서버를 목적지로 보여야 합니다. 경로 조회는 그 출발지와 목적지 쌍에 라우터가 어느 테이블을 쓸지 확인해 주며, 정책 실수는 대개 거기서 드러납니다. 어느 캡처든 나타나지 않는다면 결정 지점은 규칙을 붙인 곳이 아니라 다른 곳에 있고, 수정도 더 넓은 일치가 아니라 그곳에 속합니다.