SoftEther kapcsolati profil: importálás előtt ellenőrizze a hat mezőt

A profil importálása sikerül, de a hitelesítés meghiúsul, mert a fájl egy Virtual Hubra mutat, amelyhez a fiók soha nem csatlakozott. A fájlban semmi sem hibás; olyan elrendezést ír le, amelyhez a hitelesítő adatokat nem adták ki. Hat mező dönti el, működhet-e az import: a gazdanév, a port, a protokoll, a Virtual Hub, a felhasználói identitás, és hogy valaki tévedésből átadott-e Önnek egy rendszergazdai hitelesítő adatot. Az egy–három ellenőrzés sorrendben lefedi ezeket a mezőket, az utolsó kettő pedig magát a fájlt és azt, amihez valójában csatlakozott.

1. ellenőrzés: a gazdanév és a port

Olvassa el a gazdanevet, a portot és a megadott hozzáférési módot, mielőtt bármit importál. A natív SoftEther figyelő általában a TCP 443-on válaszol, a 992 és az 5555 pedig alternatívák, amelyeket az üzemeltetők a korlátozó hálózatok mögötti ügyfeleknek nyitnak meg. Egy olyan portra irányuló profil, amely webhelyet vagy más szolgáltatást szolgál ki, a hitelesítés előtt meghiúsul, és a hibát hitelesítő adat problémájaként jelenti. Hasonlítsa össze a párt azzal, amit az üzemeltető erre a végpontra közzétesz, ne egy katalóguslistával, amelyet valaki tavaly gyűjtött össze. Ha a gazdanév olyan címre oldódik fel, amelyet az üzemeltető soha nem említ, álljon meg ott, mert a következő lépés hitelesítő adatokat küld arra a címre.

A 443-as port közös terület, ezért a port önmagában semmit sem bizonyít a mögötte lévő szolgáltatásról. A SoftEther ügyfél a protokoll-kézfogással választja szét a kettőt, ezért előfordulhat, hogy egy profil a megfelelő portra mutat, és mégis egy webszerverhez érkezik. Ez a hiba az ügyféllogban rossz jelszónak látszik, pedig jelszót soha nem ellenőriztek.

Jegyezze fel a végpontot gazdanévként, portként és módszerként, ebben a sorrendben. Ez a hármas az a rész, amelyet kapcsolódás nélkül ellenőrizhet, és ezt idézi, amikor megkérdezi az üzemeltetőt, hogy a figyelő még fut-e. Minden, amit közzétett forrásból nem tud kitölteni, ellenőrizetlen marad, nem pedig feltételezett.

2. ellenőrzés: a protokoll dönti el az ügyfelet

Egy több hozzáférési módot kínáló szerver nem tesz egy exportált fájlt olyan profillá, amelyet minden ügyfél meg tud nyitni. Each method has its own format, its own client and its own failure mode, a keverésük pedig olyan hibákat szül, amelyek hitelesítő adat problémáknak hangzanak. Döntse el, melyik módot deklarálja a fájl, mielőtt eldönti, melyik ügyfél nyitja meg.

Az alábbi táblázat a szokásos portokat és azt sorolja fel, amire az egyes módoknak valóban szükségük van. A portok az üzemeltető választása, ezért kezelje őket alapértékként, nem pedig egy adott szerverre vonatkozó tényként. A natív SoftEther profilt a SoftEther ügyfél importálja, az ovpn csomag az OpenVPN-hez tartozik, az SSTP vagy L2TP profilokat pedig maga az operációs rendszer dolgozza fel. Egy második ügyfél telepítése egy olyan fájl megnyitásához, amelyet az első elutasít, általában a világos hibát zavaróvá változtatja.

A fájlon belüli nyilatkozatot olvassa, ne a kiterjesztést. Az OpenVPN-ről elnevezett fájl definíció szerint OpenVPN profil, míg a SoftEther profil egy kis konfiguráció, amelyet a SoftEther ügyfél importál, és a kettő nem felcserélhető. Ha a deklarált mód olyan, amelyet nem tud kiszolgálni, az megválaszolja az import kérdését.

3. ellenőrzés: a hub, a felhasználó és a rendszergazdai szerep

Natív hozzáférésnél a profil egy Virtual Hubot és egy felhasználót nevez meg benne. A hub is a logical VPN server instance with its own users and its own settings, a felhasználó pedig ennek a hubnak a tagja saját hitelesítéssel. Egyik sem szerveradminisztráció, amely a figyelőket, a hubokat és a telepítés minden felhasználóját vezérli. Egy ügyfélprofilnak soha nem szabad ezzel a vezérléssel együtt érkeznie. Amikor valaki rendszergazdai hitelesítő adatot küld, hogy az ügyfél működjön, az elrendezés hibás, akár csatlakozik, akár nem.

Tartsa külön a hármat a kapcsolat dokumentálásakor, mert különbözőképpen vonhatók vissza. Egy hub-felhasználó eltávolítása egy ember hozzáférését szünteti meg, és a telepítés többi részét érintetlenül hagyja, míg a rendszergazdai hitelesítő adat rotációja mindent érint. Ez a különbség az oka annak is, hogy egyetlen közös hub-felhasználó ellen érveljünk egy csapatnál, mivel egyetlen hitelesítő adat egyetlen visszavonási eseményt jelent mindenkinek.

4. ellenőrzés: a fájl annyira érzékeny, mint amit hordoz

A formátumtól függően a profil hordozhat mentett jelszót, tanúsítványt vagy előre megosztott kulcsot. Kezelje az exportot titokként, amíg létezik, mert a jegyhez csatolt másolat olyan másolat, amelyet más is importálhat. Ossza meg előtt távolítsa el a hitelesítő adatot, vagy osszon meg újragenerált profilt friss titokkal. A fájl érzékenysége a tartalmából ered, nem a kiterjesztéséből vagy méretéből.

Erősítse meg a végpontot az üzemeltető által közzétett csatornán, és a katalóguscímkét tekintse ellenőrizetlennek. Az országzászlót és a gazdanevet egy nyilvános csomópontlistán az választja, aki a bejegyzést beküldte, ezért egyik sem állapítja meg, ki üzemelteti a szervert. Ha a profil nyilvános katalógusból származik, az több ellenőrzésre ok, nem kevesebbre.

Jegyezze fel, honnan jött a fájl és mikor kapta. Amikor egy kapcsolat később másképp viselkedik, az eredet az első, amit az ellenőrzött végponttal összevet. Az eredet nélküli profil olyan profil, amelyet nem tud auditálni.

Az ellenőrzött példányt archiválja, ne a később találtat. Két azonos nevű, eltérő végpontú fájl az, ahogyan egy működő import támogatási esetté válik. Tartsa az ellenőrzött példányt az eredetéről szóló jegyzet mellett.

5. ellenőrzés: az alkalmazást tesztelje, ne az állapotlámpát

Az import után azt az alkalmazást tesztelje, amelyre valóban szüksége van, ne a kapcsolatjelzőt. A sikeres hitelesítés azt bizonyítja, hogy a hitelesítő adatok működnek, nem azt, hogy a várt útvonalak vagy DNS a munkamenettel együtt jöttek. Csatlakozzon, majd használja azt a szolgáltatást, amelyet a profilnak el kellett érnie.

Vizsgálja meg a hozzárendelt útvonalakat és a DNS-kiszolgálókat, és jegyezze fel, mely célpontok kerülik el az alagutat, ha a terv tartalmaz megosztást. Ezután ismételje meg egy olyan célponttal, amelyet ki kellene zárni, mert az osztott alagút, amely mindent az alagúton keresztül küld, egyetlen célpontos teszten így is átmegy. Ha egy privát erőforrás meghiúsul, az útvonal a gyanús, nem a hitelesítő adat. Jegyezze fel a négy eredményt: hitelesítve, szolgáltatás elérhető, útvonalak a vártnak megfelelőek, kizárt célpont kizárva.

Hasonlítsa össze mind a négy eredményt azzal, amit az üzemeltető ehhez a hubhoz ígért. Egy olyan munkamenet, amely hitelesít, miközben a kizárt célpont is elérhető, azt jelenti, hogy a megosztás nincs érvényben, és a profil nem a probléma. Javítsa az elvárást vagy a hub szabályzatát, majd futtassa újra a négy ellenőrzést ugyanabban a sorrendben.