Waarom een OpenVPN-profiel niet in SoftEther importeert

Twee bestanden die er allebei als een VPN-configuratie uitzien, belanden in dezelfde map, en slechts één ervan werkt. Het OpenVPN-profiel beschrijft een TLS-tunnel met richtlijnen die die client begrijpt, terwijl een SoftEther-verbinding een sessie tegen een virtuele hub beschrijft met een ander authenticatiecontract. Het ene in het andere omzetten is geen opmaakoefening, omdat de twee clients niet hetzelfde protocol implementeren. Vaststellen welke dienst de beheerder werkelijk heeft gepubliceerd, bepaalt alles wat volgt.

Twee bestanden, twee contracten

Een OpenVPN-profiel is een clientconfiguratie: een extern eindpunt, een transport, TLS-materiaal en richtlijnen voor routering en heronderhandeling. Een SoftEther-verbinding is een native clientsessie tegen een virtuele hub, met een virtuele adapter eraan gekoppeld.

Ze kunnen toegang tot hetzelfde netwerk beschrijven zonder uitwisselbaar te zijn. De OpenVPN-listener is een compatibiliteitsfunctie die de server op een aparte poort kan publiceren, en hij spreekt OpenVPN in plaats van het native protocol. De native client spreekt het native protocol en verwacht zijn eigen profiel. Eén server, twee deuren, en elke deur heeft zijn eigen sleutel.

De bestandsextensie vertelt u vrijwel niets, daarom is het antwoord van de beheerder belangrijker dan de naam van het bestand.

Lees de server voordat u een certificaatblok aanraakt

Vraag de beheerder drie dingen: welke poort en transport, welke authenticatiemethode en welke client ze verwachten dat u gebruikt. Die antwoorden nemen het meeste giswerk weg.

Bevestig daarna wat er werkelijk luistert, in plaats van wat een gids beweert. Een uitgeschakelde compatibiliteitslistener toont niets op zijn poort, en een ingeschakelde toont een socket zelfs wanneer er nooit iemand verbonden is geweest. Het verschil tussen een gesloten poort en een geweigerde aanmelding is de eerste bruikbare diagnose. Alles daarna hangt af van op welke deur er geklopt is.

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

Een UDP-poort die in de lijst met listeners ontbreekt, is een uitgeschakelde functie en geen firewallprobleem.

Wat de native client nodig heeft en een profiel niet kan geven

De native client installeert een virtuele netwerkadapter en koppelt daar een verbinding aan. Zonder die adapter is er geen interface om door te routeren, waardoor een native verbinding kan authenticeren en toch geen verkeer vervoeren.

Native authenticatie loopt tegen een virtuele hub, met een gebruikersobject dat de hubbeheerder heeft aangemaakt. Certificaatblokken die uit een OpenVPN-profiel zijn gekopieerd, worden geen hubgebruikers, en een hubgebruiker wordt geen clientcertificaat. De twee systemen bewaren verschillende dingen, en een profiel heeft nergens ruimte voor het gebruikerrecord van de hub. Dat is een structureel verschil en geen syntaxprobleem.

Houd de privésleutel buiten elke conversiedienst, want een sleutel die de machine verlaat, moet als onthuld worden beschouwd.

Wat de OpenVPN-compatibele listener accepteert

De compatibiliteitslistener is vanuit het perspectief van de client een echte OpenVPN-server: hij verwacht een OpenVPN-client en de richtlijnen die die client ondersteunt. Inline certificaatblokken zijn een OpenVPN-functie, en ze horen aan die kant van het hek.

Wat hij niet doet, is een native SoftEther-profiel accepteren, omdat dat profiel geen OpenVPN-configuratie is. De listener maakt de native client ook niet tot een OpenVPN-client. Biedt de beheerder alleen de native dienst aan, dan is het antwoord de native client; biedt hij de compatibiliteitslistener aan, dan is het antwoord OpenVPN en zijn eigen materiaal.

Vraag om de ondersteunde export van de beheerder in plaats van er zelf een uit fragmenten samen te stellen, omdat de export details bevat die een handmatig gebouwd bestand meestal mist.

Bewijs het pad voordat u richtlijnen bewerkt

Zodra de client is gekozen, test de tunnel voordat u routes aanraakt. Een geslaagde aanmelding en een interface die verkeer vervoert, zijn twee verschillende resultaten.

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

Vergelijk het toegewezen adres met de pool die de beheerder beschreef, en kijk daarna apart naar routes en resolver. Een native hubverbinding kan schoon authenticeren en helemaal geen routes installeren, wat vanaf de clientkant op een kapotte tunnel lijkt. Pas als die drie overeenkomen, is het de moeite waard een richtlijn te bewerken. Eerder bewerken verbergt welke laag fout was.