포트 1194가 이미 사용 중입니다: 그 OpenVPN 소켓은 누구의 것입니까?

같은 서버 프로필을 두 번 시작하면 두 번째 프로세스가 포트 1194에 대해 주소가 이미 사용 중이라는 오류로 종료됩니다. 흔한 경우에는 진단용 실행이 충돌을 만들었고, 원래 인스턴스는 여전히 클라이언트에 완벽하게 서비스를 제공하고 있습니다. 이 이야기는 이런 보고의 상당 부분을 설명하며, 무언가를 다시 시작하기 전에 알아볼 가치가 있습니다. 가장 저렴한 해결 버전이기도 합니다.

이 오류는 로컬 바인딩을 설명할 뿐 그 이상은 아닙니다. 공급자가 포트를 차단한다거나, 클라이언트가 잘못된 비밀번호를 보냈다거나, 인증서 체인이 깨졌다는 증거가 아닙니다.

정확한 바인딩 오류를 읽으세요

이 계열의 두 오류는 의미가 다르며, 이를 혼동하면 잘못된 계층으로 보내집니다. «주소가 이미 사용 중»은 다른 소켓이 요청한 엔드포인트를 보유하고 있다는 뜻입니다. «주소를 사용할 수 없음»은 요청한 주소가 이 호스트에 아직 존재하지 않는다는 뜻이며, 이는 중복이 아니라 준비 문제입니다.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

무언가를 바꾸기 전에 오류가 언급한 주소와 포트를 포함해 오류 텍스트를 복사하세요. 인터페이스가 나타나기를 기다리는 서비스는 두 번째 오류를 반복해서 기록한 뒤 주소가 생기면 성공적으로 바인딩하지만, 첫 번째 오류를 기록하는 서비스는 중복이 해결될 때까지 절대 성공하지 못합니다. 어느 쪽을 보았는지 적어 두는 것은 비용이 들지 않으며 헛된 인터페이스 찾기를 줄여 줍니다.

포트가 아니라 소켓을 목록화하세요

포트 번호는 불완전한 목록입니다. 엔드포인트는 전송, 주소 체계, 로컬 주소, 포트이며, 모두 하나의 네트워크 네임스페이스 안에 있습니다. 같은 번호의 UDP 리스너와 TCP 리스너는 서로 다른 소켓이고, 서로 다른 네임스페이스에 있는 같은 번호의 두 프로세스는 결코 만나지 않습니다.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

먼저 프로필이 실제로 사용하는 전송을 실행한 다음 숫자만이 아니라 로컬 주소 열을 보세요. 와일드카드 바인딩은 모든 로컬 주소를 포괄하므로, 특정 주소 하나를 요청하는 두 번째 프로세스는 인쇄된 문자열이 달라도 그것과 충돌할 수 있습니다. 소켓 재사용 옵션과 플랫폼 규칙이 정확한 결과를 결정하므로, 이것은 모든 배포에 적용하는 규칙이 아니라 관찰이어야 합니다.

어느 프로세스가 그것을 소유하는지 찾으세요

숫자 엔드포인트와 프로세스 정보는 권한이 허용할 때 소유자를 식별하며, 필요한 것은 프로그램 이름이 아니라 소유자입니다. 두 OpenVPN 프로세스가 서로 다른 프로필을 실행할 수 있고, 리스너를 가진 프로세스는 가장 예상치 못한 것일 수 있습니다.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

찾은 내용을 서비스 관리자, 컨테이너 런타임 또는 이전 테스트에서 남은 터미널 프로세스와 대조하세요. 프로세스 세부 정보가 없다고 해서 소켓에 소유자가 없다는 증거는 아니며, 보통은 쿼리가 충분한 권한 없이 실행되었다는 뜻입니다. 마찬가지로 TCP만 나열한다고 UDP 충돌이 해소되지는 않으므로 오류에 명시된 전송을 검사하세요. 프로세스 이름만으로는 어떤 프로필이 로드되었는지 결코 알 수 없으며, 바로 프로필이 엔드포인트를 결정합니다.

소유자 하나, 또는 설계된 인스턴스 둘

배포가 서버 하나를 의도한다면 수명 주기 소유자를 하나로 유지하고, 그것을 지켜보려고 두 번째 복사본을 시작하는 대신 그 인스턴스의 저널이나 설정된 로그를 읽으세요. 제어된 포그라운드 실행이 정말로 필요할 때는 관리되는 인스턴스를 의도적으로 중지하고, 그 전에 그것이 서비스하는 클라이언트를 고려하세요.

인스턴스 둘을 의도한다면 서로 다른 리스너와 주소 풀, 가상 인터페이스, 라우팅 정책, 구성 소유권을 포함한 나머지 모든 것을 다르게 주세요. 포트만 다르게 해서는 소켓 외에는 아무것도 분리되지 않으며, 두 서버는 여전히 같은 풀과 같은 경로를 두고 다툽니다.

세 가지 지름길은 이 오류에 관한 모든 스레드에 나타나므로 언급할 가치가 있습니다. 범인처럼 보이는 임의의 PID를 죽이지 마세요. 메시지를 잠재우려고 소켓 공유를 활성화하지 마세요. 서버 프로필을 클라이언트식 비바인딩 구성으로 바꾸면 바인딩 오류는 사라지지만 서버는 원래 충돌보다 진단하기 어려운 방식으로 접근 불가능해지므로, 그러지 마세요.

포트 변경은 새 리스너가 전달 규칙과 클라이언트 엔드포인트를 포함한 승인된 설계의 일부일 때만 정당한 답입니다. 그것들이 업데이트되지 않았다면, 아무도 찾을 수 없는 곳으로 충돌을 옮긴 것입니다.

무엇보다 먼저 바인딩을 확인하세요

범위가 한정된 수정 후, 의도한 인스턴스가 활성 상태인지, 그 리스너가 예상한 전송에 나타나는지, 클라이언트가 연결할 수 있는지 확인하세요. 성공적인 바인딩은 로컬 소켓 단계만 완료할 뿐, 인증이나 터널이 올라간 뒤의 트래픽에 대해서는 아무것도 증명하지 않습니다.

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

소켓이 있고 클라이언트가 여전히 실패한다면, 남은 문제는 하류에 있으며 바인딩 오류는 이제 과거입니다. 정확한 메시지를 먼저 읽는 이유는 바로 그 분리, 곧 하나의 오류, 하나의 계층, 하나의 소유자입니다. 그렇게 읽으면 다음 증상은 추측이 아니라 알려진 상태에서 시작됩니다.