Synology에서 OpenVPN 핸드셰이크가 실패하나요? LAN 전달을 확인하세요

노트북이 TLS 핸드셰이크가 실패했다고 알리므로 인증서를 다시 만들고 싶어집니다. 그 전에 더 지루한 질문을 하세요: Synology는 실제로 어느 Ethernet 포트에서 수신하고 있을까요? LAN 포트가 두 개인 NAS에는 주소가 두 개 있고, DSM의 VPN Server 패키지는 OpenVPN 수신기를 그중 하나에 묶습니다. 라우터가 1194를 다른 주소로 전달하면 패킷은 서비스에 전혀 도달하지 못하고, 클라이언트는 협상할 상대가 없습니다.

오류 문구는 클라이언트가 마지막으로 시도한 것이 아니라 처음으로 잘못된 것을 설명하므로 오해를 부릅니다. 패키지 페이지와 라우터 규칙을 비교하는 두 분이면 정리됩니다.

수신기가 묶인 주소를 찾으세요

DSM은 포트를 LAN 1과 LAN 2로 부르고, 각각 별도의 주소와 서브넷을 가집니다. VPN Server를 열고 OpenVPN 탭에 적힌 인터페이스를 읽은 다음, 제어판을 열어 DSM이 같은 인터페이스에서 가진 IPv4 주소를 적어 두세요. 전달이 지목해야 하는 것은 NAS 호스트 이름이 아니라 바로 이 두 값입니다.

케이블을 하나 더 꽂는다고 수신기가 둘이 되지는 않습니다. 두 링크 모두 연결된 것으로 보일 수 있지만 트래픽을 받는 주소는 하나뿐이며, 두 인터페이스가 같은 서브넷에 있으면 두 주소는 규칙을 저장하기 전에 아무도 다시 읽지 않는 한 자리만 다릅니다.

데몬이 실제로 무엇에 묶였는지 보여 주는 곳은 SSH로 보는 소켓 자체뿐이고, 설정 페이지의 의도가 아닙니다.

sudo netstat -anp | grep 1194

새로 추가하지 말고 기존 전달을 편집하세요

하나의 외부 포트에 규칙이 두 개 있으면 라우터가 자유롭게 고를 수 있고, 어느 것을 고를지는 펌웨어 업데이트나 재부팅 후에 바뀔 수 있습니다. 이미 있는 규칙을 열어 내부 주소를 바꾸고 저장한 다음, 다시 열어 값을 읽어 보세요. 규칙에 서비스 이름을 붙이는 것은 똑같은 전달 다섯 개가 늘어선 목록이야말로 잘못된 것이 살아남는 방식이기 때문입니다.

external 1194/udp  ->  192.0.2.20:1194/udp

내부 포트를 수신 포트와 같게 유지하고 프로토콜도 일관되게 유지하세요. UDP 1194가 기본 수신기이고, TCP 프로필은 패키지 쪽에 자체 수신기와 라우터에 대응하는 전달이 필요합니다. UDP만 수신하는 서비스로 TCP를 전달하면 오류가 아니라 침묵이 돌아옵니다.

NAS 주소가 DHCP에서 온다면 규칙을 저장하기 전에 예약하세요. 임대가 만료되면 주소가 다시 할당되고, 전달은 예전 값을 계속 가리키며, 아무도 NAS를 건드리지 않은 날에 핸드셰이크가 실패하기 시작합니다. NAS 쪽에서 정적 설정을 하면 같은 문제가 해결되지만, 주소가 라우터의 DHCP 범위 밖에 있어야 합니다.

패킷이 실제로 도착하는지 증명하세요

먼저 NAS에서 캡처를 시작한 다음 클라이언트에서 접속하고, 출력에서 출발지 주소를 읽으세요. 실패 후에 시작한 캡처는 아무것도 보여 주지 않고 아무것도 증명하지 않습니다.

sudo tcpdump -i any -n udp port 1194

침묵은 트래픽이 서비스에 도달하기 전에 죽었다는 뜻이며, 잘못된 내부 주소, DSM 방화벽에서 닫힌 포트, 관리적으로 내려간 인터페이스 중 하나입니다. 출력에 패킷이 있으면 전달은 작동하고 있으며, 남은 결함은 네트워크 계층 위에 있어 훨씬 좁은 탐색 범위가 됩니다.

캡처는 패킷이 도착한 인터페이스도 알려 주며, 바로 그 한 가지 세부가 잘못된 포트를 향한 규칙과 켜져 있지 않은 포트를 향한 규칙을 갈라놓습니다. 같은 시도 동안 라우터 자체 카운터도 지켜보세요. 캡처가 비어 있는 동안 움직이지 않는 카운터는 라우터를 가리키고, 빈 캡처와 함께 움직이는 카운터는 두 장치 사이의 경로를 가리킵니다.

패킷이 도착하면 전달을 탓하는 것을 멈추세요

다음 용의자는 프로필이고, 흔한 이유는 노후입니다. 내보낸 .ovpn 파일에는 내보낸 순간의 기관과 자료가 들어 있으므로, 나중에 인증서를 교체한 패키지는 예전 사본을 그대로 지닌 클라이언트를 거부합니다.

전송 방식도 명시적으로 확인할 가치가 있는 또 다른 불일치이며, 프로필과 패키지는 서로 다른 곳에서 편집됩니다. 패키지를 바꾸지 않고 프로필을 UDP에서 TCP로 바꾸면 클라이언트는 존재하지 않는 수신기를 기다리고, 클라이언트는 다른 모든 경우와 같은 일반적인 핸드셰이크 문구를 보고합니다. 파일에서 proto 줄을 읽고, 그다음 서버 페이지에서 선택된 프로토콜을 본 뒤에야 두 가지가 일치한다고 결론 내리세요. DSM 방화벽 규칙을 읽는 것이 세 번째 확인이며, 로컬 서브넷에서는 포트를 허용하지만 인터넷에서는 허용하지 않는 규칙은 테스트 후에 남겨 두기 쉽고, 부엌에서는 되고 다른 어디서도 실패하는 연결을 만듭니다.

원격 사용자가 실제로 지나는 경로를 시험하세요

같은 LAN 안의 클라이언트는 전달을 전혀 거치지 않고 NAS에 도달할 수 있으므로 원격 접속에 대해 아무것도 증명하지 않습니다. Wi-Fi를 끈 휴대폰을 쓰거나 네트워크 밖에 있는 사람에게 부탁하고, 그 시도 동안 라우터 카운터를 지켜보세요. 원격 시도가 실패하고 로컬 시도가 성공한다면 전달이나 방화벽이 아직 관련되어 있습니다.

작동하는 동안 외부 포트, 내부 주소, 프로토콜, 패키지 인터페이스, 프로필 이름과 내보낸 날짜라는 작동 상태를 기록하세요. 핸드셰이크가 다시 실패하면 그 메모와 현재 설정의 차이가 결함이며, 서비스가 두 포트 중 어느 것을 쓰는지 누구도 다시 알아낼 필요가 없습니다.