VPN 리스너를 의도한 인터페이스로 제한하십시오

VPN 서비스는 소켓이 바인딩된 곳이자 방화벽이 허용하는 곳 어디에서나 도달할 수 있습니다. 이는 두 가지 별개의 결정이며, 사람들은 보통 그중 하나만 내립니다. 실제 리스너를 읽는 데는 십 초면 충분하며 추측으로는 풀 수 없는 질문을 해결합니다. 거기서 시작한 다음 한 번에 하나의 제어를 바꾸십시오.

아래의 모든 내용은 호스트에서 root 또는 sudo로 명령을 실행할 수 있다고 가정합니다.

무엇이든 바꾸기 전에 소켓을 읽으십시오

Linux에서는 ss -lunp가 UDP 리스너를 로컬 주소, 포트, 프로세스와 함께 나열하고, ss -ltnp는 TCP에 대해 같은 일을 합니다. VPN의 포트를 찾아 주소 열을 주의 깊게 읽으십시오. 0.0.0.0:51820와 [::]:51820는 모든 인터페이스를 뜻하고, 10.0.0.5:51820는 한 인터페이스의 한 주소를 뜻합니다. 출력이 낯설다면 ss 매뉴얼에 열 설명이 있습니다. 프로세스 이름이 없으면 같은 명령을 sudo로 실행하십시오. 소유자 열에는 권한이 필요하기 때문입니다.

주소를 적어 두십시오. 이것이 이 안내서의 나머지 부분이 의존하는 사실입니다.

바람이 아니라 주소에 바인딩하십시오

OpenVPN은 local 지시문으로 리스너를 특정 주소에 바인딩하며, 이것이 프로세스 수준에서 범위를 좁히는 지원되는 방법입니다. 모든 구현이 동등한 기능을 제공하는 것은 아니며, 바인딩 옵션이 없는 프로토콜은 이렇게 좁힐 수 없습니다. 자신의 구현에 그런 옵션이 없다면 방화벽이 유일한 제어 수단이며, 배포 노트에 이를 분명히 적어야 합니다. 주소가 여러 개인 호스트에서는 터널 쪽 주소에 바인딩하십시오. 떠다니는 주소에 바인딩하는 것은 대개 실수입니다.

주소 변경을 견뎌야 하는 서비스에는 구성 한 줄만이 아니라 오래된 바인딩에 대한 계획이 필요합니다.

주소 패밀리를 따로 확인하십시오

IPv4와 IPv6는 별개의 소켓입니다. 0.0.0.0에 바인딩된 프로세스는 이중 스택 소켓을 통해 여전히 IPv6를 받아들일 수도 있고 아닐 수도 있으며, 이는 소켓 옵션과 플랫폼 기본값에 따릅니다. IPv4 줄만 읽는 것은 한 번 이상의 배포 검토를 속였습니다. 리스너가 좁다고 결론 내리기 전에 두 패밀리를 모두 나열하십시오.

IPv6가 설계의 일부가 아니라면 방화벽이 덮어 주리라 기대하기보다 소켓 수준에서 비활성화하는 편이 더 깔끔합니다. 이는 정책 결정이므로 나머지 인터페이스 선택과 함께 기록하십시오.

바인딩 위에 방화벽을 겹쳐 놓으십시오

좁은 바인딩은 방화벽 규칙을 대체하지 않으며, 방화벽 규칙은 와일드카드 바인딩을 좁히지 않습니다. 둘 다 사용하십시오. 구현이 지원하는 곳에서 바인딩하고, 그런 다음 그 포트에 도달해야 하는 소스에서만 허용하십시오. 클라우드 보안 그룹은 호스트 방화벽 앞에 위치하므로 경로가 VPC 경계를 넘을 때는 둘 다 확인하십시오. 유효 규칙은 두 가지의 교집합이며, 각 계층은 도달 가능성만 줄일 수 있습니다.

허용된 소스와 의도적으로 제외한 소스에서 테스트하십시오. localhost에서의 연결은 공용 경계에 대해 아무것도 증명하지 않습니다.

선택한 내용을 기록하십시오

바인딩된 주소, 이를 소유한 인터페이스, 방화벽 규칙과 그 목적을 적으십시오. 교체된 NIC나 재할당된 클라우드 주소는 누구도 프로필을 편집하지 않은 채 노출을 바꿀 수 있습니다. 클라우드 주소는 사람들이 생각하는 것보다 검토 사이에 더 자주 움직이므로 노트에 날짜를 남기십시오.

그 노트가 다음 검토를 고고학 프로젝트가 아닌 비교로 만들어 줍니다.