이 공용 VPN 노드는 실제로 어떤 프로토콜을 제공하는가?

소프트웨어가 지원하니 노드도 제공한다는 추론은 규칙이라고 부를 만큼 자주 틀립니다. SoftEther 배포는 호환되는 연결 방식 가운데 어떤 부분집합이든 활성화할 수 있고, 공용 노드는 소유자와 구성이 있는 배포입니다. 무엇으로 접속할 수 있는지는 그 노드에 달려 있으며, 그것이 실행하는 프로젝트의 기능 목록에 달려 있지 않습니다. “프로토콜이 고장 났다”는 티켓 대부분은 바로 이 둘 사이의 틈에 실제로 살고 있습니다.

프로젝트 목록이 실제로 약속하는 것

프로젝트의 프로토콜 기능은 서버가 무엇을 할 수 있는지 설명합니다. 어떤 노드는 그 리스너 중 일부를 활성화하고 다른 것은 하지 않으며, 운영자는 소프트웨어 버전을 건드리지 않고 그 집합을 바꿀 수 있습니다. 그래서 같은 빌드의 두 노드는 다르게 동작하고, 하나에 대해 동작하는 프로필은 다음 대상에 대해 아무것도 증명하지 못합니다. 어디에 접속할지 고를 때는 프로젝트 페이지보다 노드 자체의 목록이 우선합니다.

목록을 메뉴가 아니라 엔드포인트, 포트, 전송, 프로토콜 계열, 인증 방식이라는 다섯 개의 항목으로 읽으세요. 다음을 광고하는 공용 노드는 SSTP포트 위의 리스너에 대해 알려 줬을 뿐이고, 어떤 인증서를 제시하는지, 여러분의 계정이 그곳에서 동작하는지는 알려 주지 않았습니다. 이 다섯 항목을 자기 프로필과 비교하는 편이 클라이언트를 몇 번이고 다시 설치하는 것보다 빠르며, 나중에 시험해 볼 수 있는 서면 기대를 만들어 냅니다.

프로필을 그것이 지목하는 엔드포인트에 맞추세요

네이티브 SoftEther 항목이 자동으로 OpenVPN 구성이 되는 것은 아니며, 두 가지가 같은 제목 아래 같은 공급자 페이지에 함께 있어도 마찬가지입니다. 노드가 OpenVPN용으로 TCP와 UDP 리스너를 모두 공개한다면 둘을 서로 다른 엔드포인트로 다루세요. 한쪽에서 다른 쪽으로 고친 프로필은 아무도 활성화하지 않은 리스너를 가리키며, 파일의 전송 표기는 주소의 일부이지 겉치레 설정이 아닙니다.

클라이언트가 가져온 파일을 받아들인다는 것은 그 파일이 해석된다는 것만 증명합니다. 반대편에 원격 리스너가 기다리는지는 아무것도 말해 주지 않으며, 그래서 첫 연결 시도가 진짜 시험입니다. 프로토콜을 탓하기 전에 프로필의 remote 줄을 노드가 공지한 호스트와 포트와 비교하세요.

실패하는 단계를 조사하세요

웹 트래픽에 응답하는 호스트도 의도한 VPN 서비스를 갖추지 못했을 수 있습니다, 그리고 한 프로토콜을 거부하는 호스트가 모든 프로토콜에 대해 죽어 있는 것은 아닙니다. 이 두 실수는 같은 오후에 사람들을 정반대 방향으로 보냅니다. 하나는 멀쩡한 방화벽을 쫓고, 다른 하나는 애초에 문제가 아니었던 클라이언트를 다시 설치합니다. 경로마다 따로 조사하면 답은 호스트 전체가 아니라 리스너 하나를 설명하게 됩니다.

이 다섯 가지 점검은 공용 노드에서 흔한 방식을 아우르므로, 클라이언트가 쓰는 것과 같은 네트워크에서 실행하세요. 필터링된 포트는 멀리서 보면 없는 리스너와 똑같이 보이기 때문입니다.

nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example

무엇이든 바꾸기 전에 관찰한 오류를 각자의 행에 연결하세요. TLS 신원 오류는 리스너가 존재함을 증명하므로, 프로필을 다른 프로토콜로 다시 쓰면 동작하는 증거를 버리게 됩니다. 거부된 연결은 이 포트가 응답하지 않았다는 것만 증명하며, 이는 “노드가 OpenVPN을 지원하지 않는다”보다 훨씬 좁은 주장입니다.

무엇이든 바꾸기 전에 오류를 보존하세요

정확한 결과를 적으세요. 시간 초과, 인증서 신원 실패, 계정 거부, 응용 계층 거부는 서로 다른 네 가지 결말이며, 첫 번째만 프로토콜이 없다는 것에 관한 것이고 마지막만 성공한 연결 뒤의 권한에 관한 것입니다. 클라이언트를 초기화하거나 프로토콜을 바꾸면, 다음 실패가 다른 이력과 함께 비교할 기준선도 없이 찾아오기 때문에 그 구분이 무너집니다.

호환되지 않는 프로필이 동작하는 것처럼 보이게 하려고 검증을 약화하지 마세요. 인증서 검사가 꺼지면 분명한 신원 오류가 의도하지 않은 무언가로의 연결로 바뀌고, 그 결과로 얻는 성공은 어느 단계가 잘못됐는지를 감추기 때문에 원래 오류보다 나쁩니다.

노드마다 매번 다시 확인하세요

공용 노드 목록의 네이티브 SSL, OpenVPN, L2TP/IPsec, SSTP 선택지는 그 순간 그 노드의 구성을 나타냅니다. 같은 소프트웨어라도 다른 곳에서는 다른 집합을 제시할 수 있고, 공급자는 여러분의 북마크와 다음 시도 사이에 리스너를 없앨 수 있습니다. 오래된 메모는 오래된 배포를 설명합니다.

검증한 프로필을 엔드포인트와 방식과 함께 기록하고, 노드가 바뀌거나 연결이 실패하기 시작하면 조사를 다시 하세요. SoftEther 프로토콜 명세는 소프트웨어가 무엇을 할 수 있는지에 대한 참조이고, 노드 자체의 목록은 그것이 무엇을 하는지에 대한 참조입니다. 두 문서를 분리해 두면 진단이 짧아집니다.