Egy SoftEther-kiszolgáló egyszerre válaszolhat a natív SSL-porton és egy OpenVPN-kompatibilis porton, amitől a kettő egyetlen szolgáltatásnak tűnik két ajtóval. Két szolgáltatásról van szó, különböző kliensekkel, különböző konfigurációs formátumokkal és különböző képességekkel. Egy natív profil OpenVPN-kliensbe helyezése elemzéskor meghiúsul, és a hiba ritkán mondja meg, miért.

Először a figyelőt válassza, aztán a klienst.

Két figyelő, két konfigurációs formátum

A natív protokoll SoftEther-klienst és olyan kapcsolatdefiníciót használ, amely megnevezi a kiszolgálót, a portot, a virtuális hubot és a felhasználót. Az OpenVPN-kompatibilis figyelő OpenVPN-profilt vár remote utasítással, TLS-anyaggal és olyan beállításokkal, amelyek egy jóval kisebb támogatott készletből származnak, mint amit egy önálló OpenVPN-kiszolgáló nyújt. A SoftEther ezt OpenVPN-klónfunkciónak nevezi, és a klón hasznos utalás a hűségre.

A kompatibilitás verzió kérdése. Ellenőrizze, mit fogad el a telepített build, és ne azt, amit egy jelenlegi OpenVPN-kézikönyv dokumentál.

1. lépés: derítse ki, melyik figyelőt engedélyezte az üzemeltető

Kérje a figyelők listáját, ahelyett hogy egy portszámból találgatna. Egy kiszolgáló, amely TLS-sel válaszol a 443-on, nem feltétlenül OpenVPN-végpont, mert a natív protokoll ugyanazt a portot használhatja. A kézikönyv kompatibilis kiszolgálófunkciókról szóló része leírja, mely klónok léteznek, és hogyan engedélyezhetők.

Ha el tudja érni a gazdagépet, tesztelje a kapott portot, ne az oktatóanyagból vett portot: openssl s_client -connect vpn.example.com:443 -brief legalább megmondja, van-e ott TLS.

2. lépés: használja a megfelelő klienst és profilt

A natív hozzáféréshez telepítse a SoftEther-klienst, hozzon létre kapcsolatot az üzemeltető adataival, és csatolja a virtuális adaptert. A kompatibilis figyelőhöz importálja azt az OpenVPN-profilt, amelyet az üzemeltető a kiszolgálóról exportált, mert az tartalmazza a CA- és kliensanyagot, amelyet az a figyelő vár. Ne állítson össze profilt kézzel egy általános példából, és ne illesszen be natív kapcsolatdefiníciót OpenVPN-konfigurációba.

Az importáláskor jelentkező elemzési hiba formátumprobléma, nem hálózati probléma, és nem kellene a tűzfalhoz küldenie.

3. lépés: tartsa őszintén az összehasonlítást

Ha az üzemeltető mindkettőt közzéteszi, hasonlítsa össze őket úgy, hogy az eszköz, a hozzáférési hálózat és a feladat változatlan marad. A két útvonal különbözhet a hitelesítésben, azokban az alhálózatokban, amelyekhez csatlakoznak, és abban, amit a kiszolgáló később a forgalmával tesz. A közös gazdagép nem közös házirend. A feladatot is tartsa változatlanul, mert egy fájlmásolás és egy videóhívás ugyanazon útvonal különböző részeit terheli.

Álljon ellen a javításoknak, amelyek minden sikertelen importáláskor felbukkannak. A tanúsítványellenőrzések kikapcsolása vagy régi titkosítók engedélyezése egy profil átpréseléséhez visszalépés, nem kompatibilitási funkció.

4. lépés: ellenőrizze az útvonalat csatlakozás után

Csatlakozás után ellenőrizze a kapott címet, a vele érkező útvonalakat, a DNS-t és egy belső erőforrást. A natív oldalon a virtuális adapter a vizsgálandó interfész; az OpenVPN oldalon a kliens által létrehozott tun vagy tap eszköz. Mindkét esetben a kérdés az, hogy a választott figyelő kiadja-e a szükséges hozzáférést, ami külön tény attól, hogy az alagút felállt-e. Jegyezze fel a címet előtte és utána, és hasonlítsa össze őket.

Rögzítse, melyik figyelő és melyik kliensverzió eredményezte a működő eredményt. Különben a következő ember a portszámtól kezdve ismételné meg a felfedezést.

Kapcsolódó cikkek