SoftEther egen klient eller OpenVPN-profil: välj rätt port

En SoftEther-server kan svara på den egna SSL-porten och på en OpenVPN-kompatibel port samtidigt, vilket får de två att se ut som en tjänst med två dörrar. De är två tjänster med olika klienter, olika konfigurationsformat och olika förmågor. Att lägga en egen profil i en OpenVPN-klient misslyckas vid parsning, och felet säger sällan varför.

Välj lyssnaren först, sedan klienten.

Två lyssnare, två konfigurationsformat

Det egna protokollet använder en SoftEther-klient och en anslutningsdefinition som namnger servern, porten, den virtuella hubben och användaren. Den OpenVPN-kompatibla lyssnaren förväntar sig en OpenVPN-profil med ett remote-direktiv, TLS-material och alternativ från en mycket mindre stödd uppsättning än en fristående OpenVPN-server erbjuder. SoftEther kallar detta en OpenVPN-klonfunktion, och klon är en användbar ledtråd om trovärdigheten.

Kompatibilitet är en versionsfråga. Kontrollera vad den utrullade byggen accepterar, inte vad en aktuell OpenVPN-handbok dokumenterar.

Steg 1: ta reda på vilken lyssnare operatören har aktiverat

Be om lyssnarlistan i stället för att gissa utifrån ett portnummer. En server som svarar med TLS på 443 är inte nödvändigtvis en OpenVPN-slutpunkt, eftersom det egna protokollet kan använda samma port. Handbokens avsnitt om kompatibla serverfunktioner beskriver vilka kloner som finns och hur de aktiveras.

Om du når värden, testa porten du fick i stället för porten från en handledning: openssl s_client -connect vpn.example.com:443 -brief det säger åtminstone om TLS finns där.

Steg 2: använd den matchande klienten och profilen

För egen åtkomst, installera SoftEther-klienten, skapa en anslutning med operatörens uppgifter och anslut den virtuella adaptern. För den kompatibla lyssnaren, importera den OpenVPN-profil som operatören exporterade från servern, eftersom den bär det CA- och klientmaterial som lyssnaren förväntar sig. Sätt inte ihop en profil för hand från ett generiskt exempel, och klistra inte in en egen anslutningsdefinition i en OpenVPN-konfiguration.

Ett parsningsfel vid import är ett formatproblem, inte ett nätverksproblem, och det bör inte skicka dig till brandväggen.

Steg 3: håll jämförelsen ärlig

Om operatören publicerar båda, jämför dem medan enheten, åtkomstnätet och uppgiften hålls oförändrade. De två vägarna kan skilja sig i autentisering, i subnäten de ansluter till och i vad servern sedan gör med din trafik. En delad värd är inte en delad policy. Håll också uppgiften oförändrad, eftersom en filkopia och ett videosamtal belastar olika delar av samma väg.

Motstå de rättelser som dyker upp varje gång en import misslyckas. Att stänga av certifikatkontroller eller aktivera gamla chiffer för att pressa igenom en profil är en regression, inte en kompatibilitetsfunktion.

Steg 4: verifiera vägen efter anslutning

När du är ansluten, kontrollera adressen du fick, rutterna som följde med, DNS och en intern resurs. På den egna sidan är den virtuella adaptern gränssnittet att inspektera; på OpenVPN-sidan är det tun- eller tap-enheten som klienten skapade. Hur som helst är frågan om lyssnaren du valde ger den åtkomst du behöver, vilket är ett separat faktum från om tunneln kom upp. Skriv ned adressen före och efter, och jämför dem.

Notera vilken lyssnare och vilken klientversion som gav det fungerande resultatet. Annars skulle nästa person upprepa upptäckten från portnumret och uppåt.