SoftEther eigen client of OpenVPN-profiel: kies de juiste poort
Een SoftEther-server kan tegelijk een eigen listener en een OpenVPN-kloon aanbieden. Ze vragen verschillende clients en profielen, en ze kunnen verschillend beleid toepassen.
Een SoftEther-server kan tegelijk antwoorden op de eigen SSL-poort en op een OpenVPN-compatibele poort, waardoor de twee op één dienst met twee deuren lijken. Het zijn twee diensten met verschillende clients, verschillende configuratieformaten en verschillende mogelijkheden. Een eigen profiel in een OpenVPN-client zetten mislukt bij het parsen, en de fout zegt zelden waarom.
Kies eerst de listener, dan de client.
Twee listeners, twee configuratieformaten
Het eigen protocol gebruikt een SoftEther-client en een verbindingsdefinitie die de server, poort, virtuele hub en gebruiker benoemt. De OpenVPN-compatibele listener verwacht een OpenVPN-profiel met een remote-richtlijn, TLS-materiaal en opties uit een veel kleinere ondersteunde set dan een zelfstandige OpenVPN-server biedt. SoftEther noemt dit een OpenVPN-kloonfunctie, en kloon is een nuttige aanwijzing over de getrouwheid.
Compatibiliteit is een versiekwestie. Controleer wat de uitgerolde build accepteert, niet wat een actuele OpenVPN-handleiding documenteert.
Stap 1: zoek uit welke listener de operator heeft ingeschakeld
Vraag om de lijst met listeners in plaats van te gokken op basis van een poortnummer. Een server die met TLS antwoordt op 443 is niet per se een OpenVPN-eindpunt, omdat het eigen protocol dezelfde poort kan gebruiken. Het hoofdstuk in de handleiding over compatibele serverfuncties beschrijft welke klonen bestaan en hoe ze worden ingeschakeld.
Als je de host kunt bereiken, test dan de poort die je hebt gekregen en niet de poort uit een tutorial: openssl s_client -connect vpn.example.com:443 -brief het vertelt je ten minste of TLS er is.
Stap 2: gebruik de bijpassende client en het profiel
Voor eigen toegang installeer je de SoftEther-client, maak je een verbinding met de gegevens van de operator en koppel je de virtuele adapter. Voor de compatibele listener importeer je het OpenVPN-profiel dat de operator van de server heeft geëxporteerd, omdat het het CA- en clientmateriaal bevat dat die listener verwacht. Stel geen profiel met de hand samen uit een generiek voorbeeld, en plak geen eigen verbindingsdefinitie in een OpenVPN-configuratie.
Een parsefout bij het importeren is een formaatprobleem, geen netwerkprobleem, en die zou je niet naar de firewall moeten sturen.
Stap 3: houd de vergelijking eerlijk
Als de operator beide publiceert, vergelijk ze dan terwijl het apparaat, het toegangsnetwerk en de taak gelijk blijven. De twee paden kunnen verschillen in authenticatie, in de subnetten waarmee ze verbinden en in wat de server daarna met je verkeer doet. Een gedeelde host is geen gedeeld beleid. Houd ook de taak gelijk, want een bestandskopie en een videogesprek belasten verschillende delen van hetzelfde pad.
Weersta de oplossingen die opduiken telkens wanneer een import mislukt. Certificaatcontroles uitschakelen of oude ciphers inschakelen om een profiel erdoor te drukken is een regressie, geen compatibiliteitsfunctie.
Stap 4: verifieer het pad na het verbinden
Controleer na het verbinden het adres dat je hebt gekregen, de routes die erbij kwamen, DNS en één interne bron. Aan de eigen kant is de virtuele adapter de interface die je moet inspecteren; aan de OpenVPN-kant is dat het tun- of tap-apparaat dat de client heeft gemaakt. Hoe dan ook is de vraag of de listener die je koos de toegang geeft die je nodig hebt, wat een apart feit is van of de tunnel omhoog kwam. Schrijf het adres voor en na op, en vergelijk ze.
Noteer welke listener en welke clientversie het werkende resultaat opleverden. Anders zou de volgende persoon de ontdekking vanaf het poortnummer herhalen.