VPN용 클라우드 보안 그룹: 리스너만 열고 전부 열지 마라

VPN 서버는 돌아가고, 클라이언트는 타임아웃이 나며, 첫 반응은 보안 그룹에 모두 허용 규칙을 추가하는 것이다. 그것으로 될 때도 있는데, 그것이 최악의 결과다. 이제 어떤 경계가 실제로 닫혔는지 아무도 모르기 때문이다. 클라이언트와 데몬 사이에는 네 개의 별도 필터가 있고, 그중 하나만 보안 그룹이다.

규칙보다 프로토콜을 먼저 특정하라

규칙은 프로토콜, 포트 범위, 소스다. WireGuard는 UDP, 보통 51820에서 수신한다. OpenVPN 은 설정에 따라 보통 UDP 또는 TCP 1194다. IPsec은 UDP 500과 4500에서 IKE 교환에 더해 ESP 프로토콜 자체가 필요한데, 이는 포트가 아니라 프로토콜 번호다. 다른 규칙이 TCP라서 TCP로 짐작하는 것이 바로 맞아 보이지만 아무것도 맞지 않는 규칙을 만드는 길이다.

리스너는 튜토리얼이 아니라 실행 중인 서비스에서 읽어라. 한 주소에 묶인 데몬은 다른 주소로 오는 트래픽을 받지 않는다.

소스는 인터넷 전체가 아니라 설계가 허용하는 클라이언트 범위로 제한하라.

보안 그룹은 상태 저장, 서브넷 ACL은 아니다

보안 그룹은 상태 저장이며 허용만 한다. 허용된 인바운드 흐름은 응답을 자동으로 받고, 고민할 거부 규칙이 없다. 서브넷 ACL은 상태 비저장이며 양방향으로 평가되므로, 대응하는 아웃바운드 임시 범위가 없는 인바운드 허용은 여전히 실패한다. 이 차이가 콘솔에서 맞아 보이는 많은 규칙을 설명한다.

실행 중인 엔드포인트에 어떤 정책이 붙어 있는지도 확인하라. 인스턴스에 그룹이 둘 이상일 수 있고, 붙지 않은 그룹의 규칙은 아무것도 바꾸지 않는다.

실효 정책은 붙은 것들의 합집합이며, 편집한 파일이 아니다.

호스트 방화벽은 별개의 경계다

클라우드 정책은 네트워크 인터페이스까지 트래픽을 허용하고, 그다음 운영체제가 데몬이 그것을 보는지 결정한다. 기본 거부 정책을 쓰는 호스트 방화벽 은 보안 그룹이 허용한 패킷을 버리지만, 클라우드 콘솔에는 거부가 표시되지 않는다. 콘솔은 애초에 관여하지 않았기 때문이다. 패킷이 만나는 순서대로 둘 다 확인하라.

호스트가 배포판 방화벽 프런트엔드를 쓴다면 프로필 이름이 아니라 기저 규칙을 확인하라. 프로필이 활성인데 포트는 닫혀 있을 수 있다.

인터페이스에서 캡처하면 어느 경계가 패킷을 버렸는지 알 수 있다.

리스너를 허용하는 것은 클라이언트를 라우팅하는 것이 아니다

클라이언트 트래픽을 포워딩하는 VPN 게이트웨이는 열린 포트 이상이 필요하다. IP 포워딩, 터널 인터페이스에서 목적지 네트워크로 가는 흐름을 허용하는 정책, 그리고 자신에게 주소가 지정되지 않은 트래픽을 플랫폼이 버리지 않도록 인터페이스에서 소스-목적지 검사를 끄는 일이 필요하다. 어느 것도 리스너 규칙이 만들어 주지 않는다.

여기서 동작하는 핸드셰이크와 끊긴 데이터 경로가 갈라지고, 그래서 터널 상태가 건강해 보여도 아무것도 로드되지 않을 수 있다.

라우팅은 자체 검증을 갖춘 별도 변경으로 고치고, 포워딩 게이트웨이에는 목적지를 허용하는 이그레스 정책도 필요하다는 점을 기록하라.

돌아올 길을 남겨 두고, 그다음 규칙을 좁혀라

원격 방화벽 정책을 바꾸기 전에 세션 관리자, 시리얼 콘솔, 대역 외 네트워크 같은 독립적 관리 경로가 있는지 확인하라. 유일한 관리 경로가 편집하는 규칙을 지난다면 복구 수단이 없는 것이다. 그런 다음 좁은 규칙을 적용하고, 실제 클라이언트에서 시험하고, 그 시도를 서버 측 증거와 맞춰 보라. 같은 머신의 다른 서비스 응답은 리스너에 도달했다는 증거가 아니다.

좁은 허용이 동작하면 실험적 넓은 허용은 즉시 제거하고, 규칙이 왜 있는지 적어 두라. AWS는 보안 그룹의 상태 저장 동작 을 문서화하며, 누군가 지름길로 넓은 범위를 제안할 때 인용해야 할 문서가 바로 그것이다.

연결도 문서화하라. 그렇지 않으면 교체 인터페이스가 조용히 정책을 잃는다.