SoftEtherin natiivi asiakas vai OpenVPN-profiili: valitse oikea portti

SoftEther-palvelin voi vastata samanaikaisesti natiivilla SSL-portilla ja OpenVPN-yhteensopivalla portilla, mikä saa ne näyttämään yhdeltä palvelulta, jossa on kaksi ovea. Ne ovat kaksi palvelua, joilla on eri asiakkaat, eri kokoonpanomuodot ja eri ominaisuudet. Natiivin profiilin työntäminen OpenVPN-asiakkaaseen epäonnistuu jäsentämisessä, ja virhe kertoo harvoin miksi.

Valitse ensin kuuntelija ja vasta sitten asiakas.

Kaksi kuuntelijaa, kaksi kokoonpanomuotoa

Natiivi protokolla käyttää SoftEther-asiakasta ja yhteysmääritelmää, joka nimeää palvelimen, portin, virtuaalisen hubin ja käyttäjän. OpenVPN-yhteensopiva kuuntelija odottaa OpenVPN-profiilia, jossa on remote-direktiivi, TLS-materiaali ja asetuksia paljon pienemmästä tuetusta joukosta kuin itsenäinen OpenVPN-palvelin tarjoaa. SoftEther kutsuu tätä OpenVPN-kloonitoiminnoksi, ja klooni on hyödyllinen vihje tarkkuudesta.

Yhteensopivuus on versiokysymys. Tarkista, mitä käyttöön otettu versio hyväksyy, älä sitä, mitä nykyinen OpenVPN-käsikirja dokumentoi.

Vaihe 1: selvitä, minkä kuuntelijan operaattori on ottanut käyttöön

Pyydä kuuntelijaluettelo sen sijaan, että arvaisit portin numerosta. Palvelin, joka vastaa TLS:llä portissa 443, ei välttämättä ole OpenVPN-päätepiste, koska natiivi protokolla voi käyttää samaa porttia. Käsikirjan osio yhteensopivista palvelintoiminnoista kuvaa, mitkä kloonit ovat olemassa ja miten ne otetaan käyttöön.

Jos pääset isäntään, testaa portti, joka sinulle annettiin, älä opetusohjelman porttia: openssl s_client -connect vpn.example.com:443 -brief se kertoo ainakin, onko TLS paikalla.

Vaihe 2: käytä vastaavaa asiakasta ja profiilia

Natiivia käyttöä varten asenna SoftEther-asiakas, luo yhteys operaattorin tietojen kanssa ja liitä virtuaalinen sovitin. Yhteensopivaa kuuntelijaa varten tuo OpenVPN-profiili, jonka operaattori vei palvelimelta, koska se sisältää CA- ja asiakasmateriaalin, jota kuuntelija odottaa. Älä kokoa profiilia käsin yleisestä esimerkistä äläkä liitä natiivia yhteysmääritelmää OpenVPN-kokoonpanoon.

Jäsennysvirhe tuonnissa on muoto-ongelma, ei verkko-ongelma, eikä sen pitäisi lähettää sinua palomuurille.

Vaihe 3: pidä vertailu rehellisenä

Jos operaattori julkaisee molemmat, vertaa niitä pitäen laite, käyttöverkon ja tehtävä ennallaan. Kaksi polkua voivat erota todennuksessa, aliverkoissa joihin ne liittyvät ja siinä, mitä palvelin tekee liikenteellesi sen jälkeen. Jaettu isäntä ei ole jaettu käytäntö. Pidä myös tehtävä ennallaan, koska tiedoston kopiointi ja videopuhelu rasittavat saman polun eri osia.

Vastusta korjauksia, joita ilmaantuu aina, kun tuonti epäonnistuu. Varmenteen tarkistusten poistaminen käytöstä tai vanhojen salausalgoritmien ottaminen käyttöön profiilin läpi pakottamiseksi on taantuma, ei yhteensopivuusominaisuus.

Vaihe 4: varmista polku yhdistämisen jälkeen

Kun olet yhdistänyt, tarkista saamasi osoite, sen mukana tulleet reitit, DNS ja yksi sisäinen resurssi. Natiivilla puolella virtuaalinen sovitin on tarkasteltava liittymä; OpenVPN-puolella se on tun- tai tap-laite, jonka asiakas loi. Kummassakin tapauksessa kysymys on, jakaa valitsemasi kuuntelija tarvitsemasi pääsyn, mikä on erillinen tosiasia siitä, nousiko tunneli. Kirjoita osoite muistiin ennen ja jälkeen ja vertaa niitä.

Kirjaa, mikä kuuntelija ja mikä asiakasversio tuottivat toimivan tuloksen. Muuten seuraava henkilö toistaisi löydön portin numerosta alkaen.