SoftEther egen klient eller OpenVPN-profil: velg riktig port
En SoftEther-server kan eksponere både en egen lytter og en OpenVPN-klon samtidig. De trenger ulike klienter og profiler, og de kan bruke ulik policy.
En SoftEther-server kan svare på den egne SSL-porten og på en OpenVPN-kompatibel port samtidig, noe som får de to til å se ut som én tjeneste med to dører. De er to tjenester med ulike klienter, ulike konfigurasjonsformater og ulike egenskaper. Å legge en egen profil inn i en OpenVPN-klient feiler ved parsing, og feilen sier sjelden hvorfor.
Velg lytteren først, deretter klienten.
To lyttere, to konfigurasjonsformater
Den egne protokollen bruker en SoftEther-klient og en tilkoblingsdefinisjon som navngir serveren, porten, den virtuelle huben og brukeren. Den OpenVPN-kompatible lytteren forventer en OpenVPN-profil med en remote-direktiv, TLS-materiale og alternativer fra et mye mindre støttet sett enn en frittstående OpenVPN-server tilbyr. SoftEther kaller dette en OpenVPN-klonfunksjon, og klon er et nyttig hint om troverdigheten.
Kompatibilitet er et versjonsspørsmål. Sjekk hva den utrullede versjonen godtar, ikke hva en gjeldende OpenVPN-håndbok dokumenterer.
Trinn 1: finn ut hvilken lytter operatøren har aktivert
Be om lytterlisten i stedet for å gjette ut fra et portnummer. En server som svarer med TLS på 443 er ikke nødvendigvis et OpenVPN-endepunkt, fordi den egne protokollen kan bruke samme port. Håndbokens avsnitt om kompatible serverfunksjoner beskriver hvilke kloner som finnes, og hvordan de aktiveres.
Hvis du når verten, test porten du fikk i stedet for porten fra en veiledning: openssl s_client -connect vpn.example.com:443 -brief det forteller deg i det minste om TLS er der.
Trinn 2: bruk den matchende klienten og profilen
For egen tilgang, installer SoftEther-klienten, opprett en tilkobling med operatørens detaljer og koble til den virtuelle adapteren. For den kompatible lytteren, importer OpenVPN-profilen som operatøren eksporterte fra serveren, fordi den bærer CA- og klientmaterialet som den lytteren forventer. Ikke sett sammen en profil for hånd fra et generisk eksempel, og ikke lim inn en egen tilkoblingsdefinisjon i en OpenVPN-konfigurasjon.
En parsefeil ved import er et formatproblem, ikke et nettverksproblem, og den bør ikke sende deg til brannmuren.
Trinn 3: hold sammenligningen ærlig
Hvis operatøren publiserer begge, sammenlign dem mens enheten, tilgangsnettet og oppgaven holdes uendret. De to veiene kan avvike i autentisering, i subnettene de kobles til, og i hva serveren deretter gjør med trafikken din. En delt vert er ikke en delt policy. Hold også oppgaven uendret, fordi en filkopi og en videosamtale belaster ulike deler av samme vei.
Motstå rettelsene som dukker opp hver gang en import feiler. Å slå av sertifikatkontroller eller aktivere gamle chiffer for å presse en profil gjennom er en regresjon, ikke en kompatibilitetsfunksjon.
Trinn 4: verifiser veien etter tilkobling
Når du er tilkoblet, sjekk adressen du fikk, rutene som fulgte med, DNS og én intern ressurs. På den egne siden er den virtuelle adapteren grensesnittet som skal undersøkes; på OpenVPN-siden er det tun- eller tap-enheten som klienten opprettet. Uansett er spørsmålet om lytteren du valgte gir den tilgangen du trenger, noe som er et separat faktum fra om tunnelen kom opp. Skriv ned adressen før og etter, og sammenlign dem.
Noter hvilken lytter og hvilken klientversjon som ga det fungerende resultatet. Ellers ville neste person gjenta oppdagelsen fra portnummeret og opp.