SoftEther-klient eller OpenVPN-profil: vælg den rigtige port

En SoftEther-server kan svare på den indbyggede SSL-port og på en OpenVPN-kompatibel port samtidig, hvilket får de to til at ligne én tjeneste med to døre. De er to tjenester med forskellige klienter, forskellige konfigurationsformater og forskellige evner. At lægge en indbygget profil ind i en OpenVPN-klient fejler ved parsing, og fejlen siger sjældent hvorfor.

Vælg listeneren først, derefter klienten.

To listenere, to konfigurationsformater

Den indbyggede protokol bruger en SoftEther-klient og en forbindelsesdefinition, der angiver server, port, virtuelt hub og bruger. Den OpenVPN-kompatible listener forventer en OpenVPN-profil med en remote-direktiv, TLS-materiale og indstillinger fra et meget mindre understøttet sæt, end en selvstændig OpenVPN-server tilbyder. SoftEther kalder dette en OpenVPN-klonfunktion, og klon er et nyttigt fingerpeg om troskaben.

Kompatibilitet er et versionsspørgsmål. Kontroller, hvad det udrullede build accepterer, i stedet for hvad en aktuel OpenVPN-manual dokumenterer.

Trin 1: find ud af, hvilken listener operatøren har aktiveret

Bed om listenerlisten i stedet for at gætte ud fra et portnummer. En server, der svarer TLS på 443, er ikke nødvendigvis et OpenVPN-endepunkt, fordi den indbyggede protokol kan bruge samme port. Manualens afsnit om kompatible serverfunktioner beskriver, hvilke kloner der findes, og hvordan de aktiveres.

Hvis du kan nå værten, test den port, du har fået, i stedet for porten fra en vejledning: openssl s_client -connect vpn.example.com:443 -brief fortæller dig i det mindste, om TLS er der.

Trin 2: brug den matchende klient og profil

Til indbygget adgang skal du installere SoftEther-klienten, oprette en forbindelse med operatørens oplysninger og tilslutte den virtuelle adapter. Til den kompatible listener skal du importere den OpenVPN-profil, som operatøren eksporterede fra serveren, fordi den bærer det CA- og klientmateriale, som den listener forventer. Saml ikke en profil i hånden ud fra et generisk eksempel, og indsæt ikke en indbygget forbindelsesdefinition i en OpenVPN-konfiguration.

En parsefejl ved import er et formatproblem, ikke et netværksproblem, og den bør ikke sende dig til firewallen.

Trin 3: hold sammenligningen ærlig

Hvis operatøren offentliggør begge, skal du sammenligne dem, mens enhed, adgangsnetværk og opgave holdes uændrede. De to veje kan afvige i autentificering, i de subnets de tilsluttes, og i hvad serveren derefter gør ved din trafik. En delt vært er ikke en delt politik. Hold også opgaven uændret, fordi en filkopi og et videoopkald belaster forskellige dele af samme vej.

Modstå de rettelser, der dukker op, når en import fejler. At slå certifikatkontroller fra eller aktivere gamle ciphers for at presse en profil igennem er en regression, ikke en kompatibilitetsfunktion.

Trin 4: verificer vejen efter forbindelsen

Når du er forbundet, skal du kontrollere den adresse, du fik, de ruter, der fulgte med, DNS og én intern ressource. På den indbyggede side er den virtuelle adapter det interface, der skal undersøges; på OpenVPN-siden er det den tun- eller tap-enhed, som klienten oprettede. Under alle omstændigheder er spørgsmålet, om den valgte listener udleverer den adgang, du har brug for, hvilket er et separat faktum fra, om tunnelen kom op. Skriv adressen ned før og efter, og sammenlign dem.

Notér, hvilken listener og hvilken klientversion der gav det fungerende resultat. Den næste person ville ellers gentage opdagelsen fra portnummeret og op.