OpenVPN 프로필이 SoftEther로 가져오기되지 않는 이유

둘 다 VPN 구성처럼 보이는 두 파일이 같은 폴더에 들어오고, 그중 하나만 동작합니다. OpenVPN 프로필은 해당 클라이언트가 이해하는 지시문이 있는 TLS 터널을 설명하고, SoftEther 연결은 다른 인증 계약을 가진 가상 허브에 대한 세션을 설명합니다. 하나를 다른 하나로 변환하는 것은 형식 연습이 아닙니다, 두 클라이언트가 같은 프로토콜을 구현하지 않기 때문입니다. 운영자가 실제로 어떤 서비스를 게시했는지 식별하는 것이 이후의 모든 것을 결정합니다.

두 파일, 두 계약

OpenVPN 프로필은 원격 엔드포인트, 전송, TLS 자료, 그리고 라우팅과 재협상을 위한 지시문을 담은 클라이언트 구성입니다. SoftEther 연결은 가상 허브에 대한 네이티브 클라이언트 세션이며 가상 어댑터가 연결되어 있습니다.

두 파일은 같은 네트워크로의 접근을 설명할 수 있지만 서로 교환할 수는 없습니다. OpenVPN 리스너는 서버가 별도 포트에 게시할 수 있는 호환 기능이며 네이티브 프로토콜 대신 OpenVPN을 사용합니다. 네이티브 클라이언트는 네이티브 프로토콜을 사용하고 자체 프로필을 기대합니다. 하나의 서버에 두 개의 문이 있고 각 문에는 고유한 키가 있습니다.

파일 확장자는 거의 아무것도 알려주지 않으므로 운영자의 답이 파일 이름보다 중요합니다.

인증서 블록을 만지기 전에 서버를 읽으십시오

운영자에게 어떤 포트와 전송인지, 어떤 인증 방법인지, 어떤 클라이언트를 사용할 것으로 기대하는지 세 가지를 물으십시오. 그 답변들이 추측의 대부분을 없애줍니다.

그다음 안내서의 주장이 아니라 실제로 무엇이 수신 중인지 확인하십시오. 비활성화된 호환 리스너는 자기 포트에 아무것도 보여주지 않고, 활성화된 리스너는 아무도 접속한 적이 없어도 소켓을 보여줍니다. 닫힌 포트와 거부된 로그인의 차이가 첫 번째 유용한 진단입니다. 그 이후의 모든 것은 어느 문을 두드렸는지에 달려 있습니다.

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

리스너 목록에 없는 UDP 포트는 방화벽 문제가 아니라 비활성화된 기능입니다.

네이티브 클라이언트가 필요로 하지만 프로필이 줄 수 없는 것

네이티브 클라이언트는 가상 네트워크 어댑터를 설치하고 연결을 그에 묶습니다. 그 어댑터가 없으면 라우팅할 인터페이스가 없으므로 네이티브 연결이 인증을 통과하고도 트래픽을 전혀 나르지 못할 수 있습니다.

네이티브 인증은 가상 허브에 대해 수행되며 허브 관리자가 만든 사용자 객체를 사용합니다. OpenVPN 프로필에서 복사한 인증서 블록은 허브 사용자가 되지 않고 허브 사용자가 클라이언트 인증서가 되지도 않습니다. 두 시스템은 서로 다른 것을 저장하며 프로필에는 허브의 사용자 레코드를 둘 자리가 없습니다. 이것은 구문 문제가 아니라 구조적 차이입니다.

개인 키를 어떤 변환 서비스에도 넘기지 마십시오, 머신을 떠난 키는 공개된 것으로 취급해야 합니다.

OpenVPN 호환 리스너가 받아들이는 것

호환 리스너는 클라이언트 관점에서 OpenVPN 클라이언트와 그 클라이언트가 지원하는 지시문을 기대하는 실제 OpenVPN 서버입니다. 인라인 인증서 블록은 OpenVPN의 기능이며 울타리의 그쪽에 속합니다.

하지 않는 일은 네이티브 SoftEther 프로필을 받아들이는 것입니다, 그 프로필은 OpenVPN 구성이 아니기 때문입니다. 리스너는 네이티브 클라이언트를 OpenVPN 클라이언트로 바꾸지도 않습니다. 운영자가 네이티브 서비스만 제공하면 답은 네이티브 클라이언트이고, 호환 리스너를 제공하면 답은 OpenVPN과 그 자체 자료입니다.

운영자가 지원하는 내보내기를 요청하십시오, 조각으로 하나를 조립하는 대신 내보내기에는 손으로 만든 파일이 보통 놓치는 세부 사항이 담겨 있기 때문입니다.

지시문을 편집하기 전에 경로를 증명하십시오

클라이언트를 선택한 뒤에는 라우트를 만지기 전에 터널을 시험하십시오. 성공한 로그인과 트래픽을 나르는 인터페이스는 서로 다른 결과입니다.

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

할당된 주소를 운영자가 설명한 풀과 비교한 다음 라우트와 리졸버를 따로 살펴보십시오. 네이티브 허브 연결은 깨끗하게 인증되면서 라우트를 전혀 설치하지 않을 수 있고, 이는 클라이언트 쪽에서 끊긴 터널처럼 보입니다. 이 세 가지가 일치한 뒤에야 지시문을 편집할 가치가 있습니다. 더 일찍 편집하면 어느 계층이 잘못되었는지 가려집니다.