OpenVPN Access Server는 실제로 어느 포트에서 수신 대기하는가?

실행하는 명령은 ss -lntup 입니다. Access Server 호스트에서 이것을 실행하면 예상의 두 배 길이의 목록이 나옵니다. 항목의 절반은 설정 중 아무도 언급하지 않은 데몬 형태의 포트입니다. 반사적으로 443과 1194가 아닌 모든 것을 닫으면 자신의 클라이언트 포털을 망가뜨리게 됩니다.

Access Server는 하나의 리스너가 아닙니다. VPN 서비스이자 웹 서비스이며 클러스터 참여자이고, 구성한 TCP 데몬 수에 따라 데몬 전용 포트와 방화벽 리디렉션을 추가로 만들 수 있습니다.

목록을 순서대로 살펴보십시오. 소켓을 읽고, 익숙한 항목을 대응시키고, 나머지를 소유자와 바인드로 분류한 다음, 실제로 무엇이 그것을 공개하는지 확인하십시오.

읽기 전용 명령 하나로 시작하십시오

sudo ss -lntup 는 수신 대기하는 각 소켓의 전송 방식, 로컬 주소, 포트, 소유 프로세스를 보여 줍니다. 플래그가 중요합니다: -l 는 수신, -n 는 숫자 표시, -t 는 TCP, -u 는 UDP, -p 는 프로세스입니다. root 없이는 소켓은 얻지만 프로세스 이름은 얻지 못하는데, 분류에 필요한 것이 바로 그 열입니다.

어떤 의견을 만들기 전에 각 행마다 네 가지 필드를 기록하십시오: 프로토콜, 바인드 주소, 포트, 명령. Access Server 버전과 구성된 데몬 수를 그 목록 옆에 두십시오. 둘 다 기대치를 바꿉니다.

같아 보이는 두 행은 같지 않습니다. 같은 번호의 TCP와 UDP는 노출 범위가 다른 별개의 소켓이고, 0.0.0.0 과 :: 은 서로 다른 주소 패밀리에 대한 별개의 바인드입니다. 127.0.0.1 에만 바인드된 서비스는 다른 호스트에서 직접 도달할 수 없지만 로컬 리디렉션이 여전히 공개할 수 있습니다.

알아보아야 할 리스너

이 기본값은 대부분의 배포를 포괄하며 비교 기준을 제공합니다. 기본값일 뿐 완전한 허용 목록은 아닙니다.

그 이상의 모든 것에는 설명이 필요하며 추측으로는 부족합니다. 제품이 스스로를 위해 설치하는 구성 요소에 속한 로컬 전용 리스너를 자주 보게 됩니다. 기억한 포트 번호가 아니라 PID와 서비스 구성으로 확인하고, 낯설다는 이유만으로 알 수 없는 포트를 적대시하지 마십시오.

익숙한 쌍 밖의 소켓도 자동으로 잔여물은 아닙니다. TCP 데몬을 여러 개 구성하면 Access Server가 데몬별 리스너를 만들고 트래픽을 그리로 리디렉션하므로, 그 수와 포트 값은 해당 구성에 따릅니다.

무엇이든 닫기 전에 분류하십시오

불확실한 각 행에 대해 다음 순서로 세 가지 질문에 답하십시오.

1. 소유자와 목적. PID를 유닛이나 프로세스에 대응시키고 해당 서비스의 구성을 읽으십시오. 소유자를 지목할 수 없다면 소켓에 대해 무엇도 결정할 준비가 되지 않은 것입니다.
2. 바인드 범위. 루프백은 네임스페이스 내부에 국한됩니다. 와일드카드 바인드는 라우팅, 호스트 필터링, 클라우드 수준의 규칙이 허용할 때만 도달할 수 있으므로 바인드 주소는 필요조건이지 충분조건이 아닙니다. IPv4와 IPv6를 별개의 결정으로 확인하십시오.
3. 공개 경로. 서비스 포워딩, 데몬 전용 리디렉션, 외부 프록시, 실제로 적용되는 방화벽 정책을 찾으십시오. 사람들이 건너뛰는 단계가 바로 이것이며, 무해해 보이는 백엔드 포트를 도달 가능한 관리 경로로 바꾸는 것도 이 단계입니다.

같은 질문도 호스트 밖에서 보면 다르게 읽힙니다. 호스트 방화벽 규칙이 없는 포트도 클라우드 보안 그룹이 닫을 수 있고, 허용적인 호스트 규칙이 있는 포트도 아무것도 그리로 라우팅하지 않으면 도달할 수 없습니다. 목록의 결론을 쓰기 전에 양쪽 끝을 보십시오.

공개 경로가 소켓 목록과 다른 지점

Access Server 자체 문서가 가장 혼란을 일으키는 경우를 다룹니다. TCP 데몬을 여러 개 실행하면 앞쪽 포트가 데몬 전용 포트로 포워딩되고, 보이는 배치가 소켓 목록과 더 이상 일치하지 않습니다. 웹 인터페이스 필터링 자습서 는 그 규칙과, 분명한 포트만을 위해 작성한 필터가 리디렉션된 경로를 완전히 놓칠 수 있는 이유를 설명합니다.

클러스터 제어는 버전이 중요한 두 번째 지점입니다. 3.0 이상에서는 943을 공유하고, 오래된 클러스터 구성은 945를 사용했습니다. 버전을 확인하지 않고 둘 중 하나를 열거나 차단하면 정돈되어 보이지만 틀린 목록이 만들어집니다.

따라서 외부에서 보이는 표면은 세 가지의 합집합입니다: 수신 대기하는 소켓, 그것을 다시 공개하는 포워딩 규칙, 호스트 앞의 네트워크 제어입니다. 첫 번째만 기록하는 목록은 불완전하고, 첫 번째만 고려하는 변경은 경로를 열어 두거나 서비스를 끊어 버립니다.

변경 후에는 반드시 검증하십시오

지원되는 구성 소유자를 통해 리스너 설정을 변경하고, 그동안 복구 콘솔을 열어 두십시오. 원격 호스트의 웹 UI에 대한 관리 접근을 잃으면 방금 비활성화한 VPN으로는 복구할 수 없습니다.

그다음 배포에 보통 필요한 네 가지를 검증하십시오: VPN 클라이언트가 연결되고, 클라이언트 포털이 로드되고, 관리 접근이 작동하고, 노드를 둘 이상 운영하면 클러스터 통신이 여전히 작동해야 합니다. VPN만 시험하면 포털이 망가진 상태에서도 쉽게 통과합니다.

마무리로 각 서비스의 허용 경로를 적으십시오: 어떤 소켓, 어떤 바인드, 어떤 포워딩 규칙, 어떤 네트워크 제어인지. 그 문서가 유용한 보안 산출물입니다. 최소 소켓 수는 그렇지 않고, 아무도 식별을 마치지 못한 리스너를 닫는 일괄 초기화도 그렇지 않습니다.