Miért nem importálható az OpenVPN-profil a SoftEtherbe

Két fájl, amely mindkettő VPN-konfigurációnak látszik, ugyanabba a mappába kerül, és csak az egyik működik. Az OpenVPN-profil egy TLS-alagutat ír le olyan direktívákkal, amelyeket az a kliens ért, míg a SoftEther-kapcsolat egy virtuális hubbal szembeni munkamenetet ír le más hitelesítési szerződéssel. Az egyiket a másikká alakítani nem formázási gyakorlat, mert a két kliens nem ugyanazt a protokollt valósítja meg. Annak megállapítása, hogy az üzemeltető valójában melyik szolgáltatást tette közzé, mindent eldönt, ami következik.

Két fájl, két szerződés

Az OpenVPN-profil klienskonfiguráció: távoli végpont, átvitel, TLS-anyag és direktívák az útválasztáshoz és az újratárgyaláshoz. A SoftEther-kapcsolat natív kliens-munkamenet egy virtuális hubbal szemben, amelyhez virtuális adapter csatlakozik.

Leírhatják ugyanazon hálózat elérését anélkül, hogy felcserélhetők lennének. Az OpenVPN-figyelő egy kompatibilitási funkció, amelyet a szerver külön porton tehet közzé, és a natív protokoll helyett OpenVPN beszél. A natív kliens a natív protokollt beszéli, és a saját profilját várja. Egy szerver, két ajtó, és minden ajtónak megvan a maga kulcsa.

A fájlkiterjesztés szinte semmit nem mond el Önnek, ezért az üzemeltető válasza fontosabb, mint a fájl neve.

Olvassa el a szervert, mielőtt tanúsítványblokkhoz nyúl

Kérdezzen meg három dolgot az üzemeltetőtől: melyik port és átvitel, melyik hitelesítési módszer, és melyik klienst várják Öntől. Ezek a válaszok megszüntetik a találgatások nagy részét.

Ezután erősítse meg, mi figyel valójában, és ne azt, amit egy útmutató állít. Egy letiltott kompatibilitási figyelő semmit nem mutat a portján, egy engedélyezett pedig foglalatot mutat akkor is, ha soha senki nem csatlakozott. A zárt port és az elutasított bejelentkezés közötti különbség az első hasznos diagnózis. Minden utána attól függ, melyik ajtón kopogtattak.

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

A figyelők listájából hiányzó UDP-port letiltott funkció, nem tűzfalprobléma.

Mire van szüksége a natív kliensnek, amit egy profil nem adhat meg

A natív kliens virtuális hálózati adaptert telepít, és kapcsolatot köt hozzá. Az adapter nélkül nincs milyen felületen útválasztani, ezért egy natív kapcsolat hitelesíthet, és mégsem szállít forgalmat.

A natív hitelesítés virtuális hubbal szemben fut, egy felhasználói objektummal, amelyet a hub rendszergazdája hozott létre. Az OpenVPN-profilból másolt tanúsítványblokkok nem válnak hubfelhasználóvá, és egy hubfelhasználó nem válik kliens-tanúsítvánnyá. A két rendszer különböző dolgokat tárol, és a profilnak nincs helye a hub felhasználói rekordja számára. Ez szerkezeti különbség, nem szintaktikai probléma.

Tartsa a privát kulcsot minden konvertáló szolgáltatáson kívül, mert a gépet elhagyó kulcsot nyilvánosságra kerültként kell kezelni.

Mit fogad el az OpenVPN-kompatibilis figyelő

A kompatibilitási figyelő a kliens szemszögéből valódi OpenVPN-szerver: OpenVPN-klienst és az általa támogatott direktívákat várja. A soron belüli tanúsítványblokkok OpenVPN-funkciók, és a kerítés azon oldalához tartoznak.

Amit nem tesz meg: nem fogad el natív SoftEther-profilt, mert az a profil nem OpenVPN-konfiguráció. A figyelő a natív klienst sem alakítja OpenVPN-klienssé. Ha az üzemeltető csak a natív szolgáltatást kínálja, a válasz a natív kliens; ha a kompatibilitási figyelőt kínálja, a válasz az OpenVPN és a saját anyaga.

Kérje az üzemeltető által támogatott exportot ahelyett, hogy töredékekből állítana össze egyet, mert az export olyan részleteket hordoz, amelyeket egy kézzel épített fájl rendszerint kihagy.

Bizonyítsa az útvonalat, mielőtt direktívákat szerkeszt

Miután a klienst kiválasztotta, tesztelje az alagutat, mielőtt az útvonalakhoz nyúl. A sikeres bejelentkezés és a forgalmat szállító felület két különböző eredmény.

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

Hasonlítsa össze a kiosztott címet az üzemeltető által leírt készlettel, majd nézze meg külön az útvonalakat és a feloldót. Egy natív hubkapcsolat tisztán hitelesíthet, és egyáltalán nem telepít útvonalakat, ami a kliens oldaláról törött alagútnak látszik. Csak ha ez a három egyezik, érdemes direktívát szerkeszteni. A korábbi szerkesztés elrejti, melyik réteg volt hibás.