VPN 포트가 응답하지 않는다면? 리스너, 바인드 주소, 호스트 방화벽

VPN이 포트에서 아무 응답도 하지 않는데, 두 가지 가능한 원인은 정반대의 수리를 요구합니다. 소켓을 연 프로세스가 없는 경우와, 소켓은 있는데 기계 사이의 무언가가 패킷을 막는 경우입니다. 이 질문의 앞 절반은 명령 한 번으로 판정되므로 방화벽 규칙을 건드리기 전에 둡니다. 아래 순서는 추측을 더하는 대신 단계마다 설명을 하나씩 지웁니다. 둘 사이에서 추측하는 것이야말로 십 분 진단을 저녁 내내로 만드는 일입니다.

서버에 로그인할 수 있고, 클라이언트가 스캐너가 아닌 실제 프로필이라고 가정합니다. 두 가정 모두 중요합니다. 일반적인 프로브는 프로토콜 고유의 질문에 답할 수 없기 때문입니다.

소켓이 애초에 존재하는가

서비스가 자기 자신에 대해 말하는 것부터 시작하십시오: 기동했는지, 그리고 더 유용하게는 첫 기동 오류가 무엇이었는지입니다. 파싱 실패, 누락된 키, 바인드 오류는 리스너가 생기지 못하게 하고, 프로세스는 상태 줄이 모호하게 읽힐 만큼 조용히 종료될 수 있습니다. 활성이라고 보고하는 유닛은 그 자체로 증거가 아닙니다, 주 프로세스는 살아 있는데 포트를 바인드해야 할 구성 요소가 이미 포기했을 수 있기 때문입니다.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

소켓 목록이 나머지 진단이 기대는 사실입니다. 포트만이 아니라 로컬 주소 열을 읽으십시오. 루프백 바인드와 잘못된 인터페이스 바인드는 그 열에서 드러납니다. 127.0.0.1에 존재하는 리스너는 완벽하게 동작하며, 그런데도 노트북에서는 보이지 않습니다.

소켓이 어느 주소와 주소 체계로 응답하는가

두 가지 실수는 클라이언트 쪽에서 똑같이 보이며 대부분의 "연결할 수 없음" 보고를 설명합니다. 루프백 주소에 바인드된 서버는 다른 기계의 트래픽을 절대 받지 않고, IPv4 주소에만 바인드된 서버는 같은 호스트의 IPv6 주소로 거는 클라이언트에 절대 응답하지 않습니다. 정책에 대해 무엇이든 가정하기 전에 소켓 표의 주소와 클라이언트가 실제로 거는 주소를 글자 하나씩 비교하십시오.

목록을 한 포트로 제한하면 호스트가 여러 서비스를 돌릴 때도 읽기 쉬운 상태를 유지하며, sport 필터는 시험하는 전송 계층과 함께 포트를 취합니다.

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

프로토콜 열이 답을 통째로 바꾼다

소켓 표는 포트뿐 아니라 프로토콜로도 키가 잡히며, 둘은 독립된 항목입니다. 1194에서 TCP에 응답하는 서비스는 UDP 1194에서 무언가 듣고 있는지에 대해 아무것도 말해 주지 않으며, 클라이언트는 항상 둘 중 하나만 사용합니다. 서버 설정이 어느 전송 계층을 고르는지, 클라이언트 프로필이 어느 것을 보내는지 확인한 다음 바로 그 행을 찾으십시오.

UDP에는 두 번째 주름이 있습니다. 인증되지 않은 프로브는 서비스가 대답해야 할 오류가 아닙니다. 포트를 조용하다고 보고하는 스캔은 서비스의 가용성이 아니라 신중함을 측정한 것이므로, 실제 클라이언트와 프로필로 시험하십시오.

시도는 한 번, 살펴볼 곳은 세 군데

승인된 클라이언트에서 정확히 한 번 시도하고 시각을 초 단위로 적어 두십시오. 그다음 그 시간대에 대해 세 출처를 읽습니다. 제공자의 네트워크 규칙 또는 콘솔, 호스트 방화벽의 카운터 또는 로그, 서비스 자체의 로그입니다. 한 번만 해 두는 것이 세 증언을 비교 가능하게 만들며, 아무도 시각을 기록하지 않은 시도를 반복하는 것보다 비용이 적습니다.

두 결과는 반대 방향을 가리킵니다. 패킷이 호스트에 도달하지 않았다면 경로가 그것을 버리고 있고 리스너는 무관합니다. 패킷이 소켓에 도착했는데 서비스가 거부했다면 경로는 정상이고 답은 프로토콜, 암호, 자격 증명에 있습니다. 이미 연결을 받아들인 서비스를 위해 포트를 여는 것은 다음 진단을 쉽게가 아니라 어렵게 만듭니다.

규칙을 바꾸기 전에 단계를 이름 붙이십시오

협상이 시작되고 인증이 실패하는 것은 하나의 장애이며, 전달이 막힌 채 터널이 수립되는 것은 전혀 다른 장애입니다. 단계를 먼저 이름 붙이면 수리가 좁게 유지됩니다. 자격 증명 문제는 방화벽 규칙으로 고쳐지지 않고, 데이터 경로 문제는 재시작으로 고쳐지지 않습니다.

질문에 답하는 가장 좁은 진단을 쓰십시오. 관리자의 통제 아래 한 포트에서 잠시 패킷을 관찰하는 것은 합리적인 도구입니다. 방화벽 전체를 끄는 것은 아닙니다. 결과를 무엇에 귀속시킬 수 없게 되기 때문입니다. ss 문서는 위에서 쓴 필터를 다루며, 어떤 캡처보다 값싼 첫 단계입니다. 두 갈래 중 무엇을 증명했는지 기록하면 다음 발생은 알려진 답에서 시작합니다.