Miksi OpenVPN-profiilia ei voi tuoda SoftEtheriin

Kaksi tiedostoa, jotka molemmat näyttävät VPN-määritykseltä, päätyvät samaan kansioon, ja vain toinen niistä toimii. OpenVPN-profiili kuvaa TLS-tunnelin direktiiveillä, jotka kyseinen asiakas ymmärtää, kun taas SoftEther-yhteys kuvaa istunnon virtuaalista keskitintä vastaan erilaisella todennussopimuksella. Toisen muuntaminen toiseksi ei ole muotoiluharjoitus, koska kaksi asiakasta eivät toteuta samaa protokollaa. Sen selvittäminen, minkä palvelun ylläpitäjä todella julkaisi, ratkaisee kaiken seuraavan.

Kaksi tiedostoa, kaksi sopimusta

OpenVPN-profiili on asiakasmääritys: etäpäätepiste, kuljetus, TLS-materiaali ja direktiivit reititykseen ja uudelleenneuvotteluun. SoftEther-yhteys on natiivi asiakasistunto virtuaalista keskitintä vastaan, ja siihen on liitetty virtuaalinen sovitin.

Ne voivat kuvata pääsyä samaan verkkoon olematta vaihtokelpoisia. OpenVPN-kuuntelija on yhteensopivuusominaisuus, jonka palvelin voi julkaista erillisellä portilla, ja se puhuu OpenVPN natiivin protokollan sijaan. Natiivi asiakas puhuu natiivia protokollaa ja odottaa omaa profiiliaan. Yksi palvelin, kaksi ovea, ja kummallakin ovella on oma avaimensa.

Tiedostopääte ei kerro sinulle juuri mitään, siksi ylläpitäjän vastaus on tärkeämpi kuin tiedoston nimi.

Lue palvelin ennen kuin kosket sertifikaattilohkoon

Kysy ylläpitäjältä kolme asiaa: mikä portti ja kuljetus, mikä todennusmenetelmä ja minkä asiakkaan he odottavat sinun käyttävän. Ne vastaukset poistavat suurimman osan arvailusta.

Vahvista sitten, mikä todella kuuntelee, eikä mitä opas väittää. Pois käytöstä oleva yhteensopivuuskuuntelija ei näytä portillaan mitään, ja käytössä oleva näyttää pistokkeen, vaikka kukaan ei olisi koskaan yhdistänyt. Suljetun portin ja hylätyn kirjautumisen ero on ensimmäinen hyödyllinen diagnoosi. Kaikki sen jälkeen riippuu siitä, mihin oveen koputettiin.

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

Kuuntelijaluettelosta puuttuva UDP-portti on pois käytöstä oleva ominaisuus eikä palomuuriongelma.

Mitä natiivi asiakas tarvitsee ja mitä profiili ei voi antaa

Natiivi asiakas asentaa virtuaalisen verkkosovittimen ja sitoo yhteyden siihen. Ilman sitä sovitinta ei ole rajapintaa, jonka kautta reitittää, minkä vuoksi natiivi yhteys voi todentua ja silti kuljettaa liikennettä lainkaan.

Natiivi todentaminen tapahtuu virtuaalista keskitintä vastaan, käyttäjäobjektilla, jonka keskitimen ylläpitäjä loi. OpenVPN-profiilista kopioidut sertifikaattilohkot eivät muutu keskitimen käyttäjiksi, eikä keskitimen käyttäjä muutu asiakassertifikaatiksi. Kaksi järjestelmää tallentaa eri asioita, eikä profiililla ole paikkaa keskitimen käyttäjätietueelle. Se on rakenteellinen ero eikä syntaksiongelma.

Pidä yksityinen avain poissa jokaisesta muunnospalvelusta, koska koneelta lähtevää avainta on pidettävä paljastuneena.

Mitä OpenVPN-yhteensopiva kuuntelija hyväksyy

Yhteensopivuuskuuntelija on asiakkaan näkökulmasta todellinen OpenVPN-palvelin: se odottaa OpenVPN-asiakasta ja direktiivejä, joita kyseinen asiakas tukee. Sisäiset sertifikaattilohkot ovat OpenVPN-ominaisuus, ja ne kuuluvat aidan sille puolelle.

Mitä se ei tee, on natiivin SoftEther-profiilin hyväksyminen, koska se profiili ei ole OpenVPN-määritys. Kuuntelija ei myöskään muuta natiivia asiakasta OpenVPN-asiakkaaksi. Jos ylläpitäjä tarjoaa vain natiivia palvelua, vastaus on natiivi asiakas; jos hän tarjoaa yhteensopivuuskuuntelijan, vastaus on OpenVPN ja sen oma materiaali.

Pyydä ylläpitäjän tukema vienti sen sijaan, että kokoaisit sellaisen paloista, koska vienti kantaa yksityiskohtia, jotka käsin rakennettu tiedosto yleensä jättää huomaamatta.

Todista polku ennen direktiivien muokkaamista

Kun asiakas on valittu, testaa tunneli ennen reitteihin koskemista. Onnistunut kirjautuminen ja liikennettä kuljettava rajapinta ovat kaksi eri tulosta.

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

Vertaa myönnettyä osoitetta ylläpitäjän kuvaamaan altaaseen ja katso sitten reittejä ja selvittäjää erikseen. Natiivi keskitinyhteys voi todentua puhtaasti eikä asentaa yhtään reittiä, mikä näyttää asiakkaan puolelta rikkinäiseltä tunnelilta. Vasta kun nuo kolme täsmäävät, direktiiviä kannattaa muokata. Aikaisempi muokkaaminen peittää, mikä kerros oli väärin.