VPN 클라이언트 트래픽과 방화벽 상태: 바깥 흐름과 안쪽 흐름

VPN 핸드셰이크가 끝나고 클라이언트가 주소를 받았는데도 게이트웨이 뒤의 서비스는 여전히 연결을 거부한다. 방화벽은 흔히 시킨 대로 정확히 하고 있다. 허용한 것은 바깥 터널 흐름이며, 이는 캡슐 해제된 응용 프로그램 연결과 다른 패킷이다. 여기서 어떤 흐름을 허용하는지, 그리고 경계가 상태를 아예 추적하는지라는 두 가지 결정이 나온다.

이 둘을 분리하기 전까지는 모든 규칙 변경이 추측이다.

방화벽은 서로 다른 두 패킷을 본다

캡슐 해제 전에 방화벽은 VPN 종단점으로 향하는 트래픽, 즉 리스너로 가는 바깥 UDP 흐름을 본다. 캡슐 해제 후 전달되는 패킷은 클라이언트의 안쪽 주소와 서비스 목적지를 담는다.

바깥 흐름에 대한 허용은 전달되는 TCP 연결을 승인하지 않는다. 둘은 서로 다른 체인에서, 서로 다른 인터페이스에 대해, 변환 후 서로 다른 주소로 평가될 수 있다.

양쪽의 동등한 위치에서 캡처한 것을 비교한다. 터널 경계의 캡처와 서버의 캡처는 같은 세션에 대해 다른 튜플을 보여 준다.

첫 번째 결정: 터널인가 서비스인가

클라이언트가 VPN 종단점 자체만 필요하다면 바깥 허용으로 충분할 수 있다. 게이트웨이 너머의 서비스가 필요하다면 그 목적지와 포트에 대한 전달 허용이 필요하다. 서비스까지 허용하는 터널 규칙은 이름 붙여야 할 설계 선택이며 우연이 아니다.

클라이언트 범위와 서비스 범위를 좁게 유지한다. 터널 서브넷에서 전체 LAN으로 가는 허용은 모든 호스트를 신뢰하겠다는 결정이며, 한 응용 프로그램을 위한 지름길이 아니다.

두 규칙을 따로 적는다. 터널 규칙과 서비스 규칙은 서로 다른 방식으로 실패하고 서로 다른 증거로 디버깅된다. 하나가 실패하면 어느 계층을 먼저 볼지 알 수 있다.

두 번째 결정: 각 경계에서 상태를 둘 것인가

확립된 흐름 규칙은 허용된 교환의 응답을 통과시킬 수 있지만 그 동작은 제품에 달려 있다. 클라우드 보안 그룹은 보통 상태를 유지하고, 서브넷 ACL은 흔히 상태를 유지하지 않으며 양방향 모두 명시적 처리가 필요하다. 경로의 모든 경계가 상태를 같은 방식으로 다룬다고 가정하지 마라. 규칙을 설계하기 전에 각 경계를 나열하고 상태 유지 여부를 표시하라.

규칙이 바뀌면 기존의 추적된 흐름은 계속 동작하고 새 흐름은 실패할 수 있으며, 그 반대도 마찬가지다. 그 차이는 유용한 단서이며, 운용 중인 게이트웨이에서 모든 연결 상태를 비울 이유는 아니다.

새롭게 통제된 요청으로 시험하고 관련 카운터를 확인하라. 깨끗한 시험이 방해가 되는 재설정보다 낫다. 변경 기록에 카운터 이름을 적어 다음 시험이 같은 증거를 쓰게 하라.

같은 정책으로 반환 경로를 검증하라

클라이언트에서 서비스로 새 요청을 보낸 뒤 각 경계에서 전달 및 반환 카운터를 확인하라. 변환이 관련되면 특히, 응답이 예상한 경로를 쓰는지 확인하라.

의도한 클라이언트 범위와 서비스 범위를 좁게 유지하고, 요청을 허용한 것과 같은 규칙 집합으로 반환 경로를 검증하라. 오래된 흐름이 아직 열려 있어서만 동작하는 규칙은 동작하는 규칙이 아니다.