A SoftEther virtuális adaptere megjelenik az operációs rendszer hálózati listáján, kihúzottként jelenti magát, és semmilyen forgalmat nem szállít. Ez a kombináció normális olyan eszköznél, amelyhez nincs munkamenet csatolva, és ez az az állapot is, amelyet akkor lát, ha rossz profil van hozzá kötve. Az adapter olyan eszköz, amely az operációs rendszer tulajdonában van; a munkamenet az, ami életet ad neki. Vegye sorra ezt a négy ellenőrzést, és álljon meg az elsőnél, amelyik sikertelen.

Válassza el az eszközt a munkamenettől

Az adapter létrehozása hálózati eszközt telepít; nem hitelesít semmilyen kiszolgáló felé. Mielőtt bármit is kiolvasna az interfész állapotából, ellenőrizze, mit mond a kliens kapcsolatlistája. Az a profil, amely nincs csatlakoztatva, minden további vizsgálat nélkül megmagyarázza a kihúzott állapotot.

Az adapternek és a fizikai interfésznek más a feladata. Az egyik az alkalmazások által látott visszafejtett forgalmat szállítja, a másik pedig a titkosított külső kapcsolatot szállítja a kiszolgáló felé. A kettő összekeverése azt eredményezi, hogy a tűzfal-szabályok és az útvonalak a rossz eszközre kerülnek. A fizikai interfészhez írt szabályok nem fognak egyezni az alagút forgalmával, és az alagúthoz írt szabályok nem hatnak a külső kapcsolatra.

Párosítson egy adaptert egy profilhoz

Minden adaptert ahhoz a kapcsolatprofilhoz kell kötni, amelyet szán, és a kötésnek a kliensben láthatónak kell lennie, nem emlékezetben tartottnak. Ha több adapter van, jegyezze fel, melyik profil melyik eszközt birtokolja, mielőtt bármelyikhez hozzányúl. Az adapter profilok közötti újrafelhasználása az, amitől egy elavult cím túlél egy újracsatlakozást.

Ha a kliens támogatott módot kínál a kötés újbóli létrehozására, használja azt ahelyett, hogy közvetlenül szerkesztené az operációs rendszer konfigurációját. A kliens csatlakozáskor írja az adapter beállításait, ezért a kézi módosítások általában eltűnnek, vagy a következő munkamenetben ütköznek.

Csatlakozás után olvassa ki a tényleges beállításokat

Amikor a munkamenet létrejött, olvassa ki a címet, az útvonalat és a feloldót a rendszerből. A kliens állapotpanelje azt írja le, mit kért, a kernel pedig azt, mi történt valójában.

ip -brief address show
ip route get 10.20.30.41
resolvectl status | head -20

A címlista megmutatja, kapott-e egyáltalán valamit az adapter, és a sikeres bejelentkezés után cím nélküli adapter a profil konfigurációjára utal, nem az illesztőprogramra. Az útvonal-lekérdezés megmutatja, melyik interfész vinné egy magáncélú célállomást, és ott válik láthatóvá a hiányzó útvonal. A feloldó kimenete megmutatja, követte-e a DNS a munkamenetet, mivel egy helyi DNS-sel működő kapcsolat még mindig félig törött kapcsolatot ad.

Egy hasznos beállítások nélkül létrehozott adapter létezhet együtt egy sikeres felügyeleti bejelentkezéssel a kliens más pontján. A két panel különböző kérdésekre válaszol, ezért az egyik soha nem bizonyíték a másikról. Amikor ellentmondanak egymásnak, a rendszer nézete az, amelyet az alkalmazások megtapasztalnak.

Álljon meg áthidalás vagy törlés előtt

A virtuális adapter áthidalása egy fizikaival tervezési változtatás, nem javítás. Két hálózati határt olvaszt össze, és nem módja a hiányzó útvonal javításának. Ha a telepítésnek erre az elrendezésre van szüksége, akkor engedélyezett tervre és teszttervre van szüksége.

Az adapter törlése ugyanolyan pusztító, ha egy másik szolgáltatás használja. Először azonosítsa a tulajdonost, beleértve a gépen lévő bármely más klienst vagy virtualizációs terméket, amely hasonló nevű interfészt hozott létre. Az eszköz, amely eltávolítás után újra megjelenik, azt mondja, hogy valami újra létrehozza.

Fejezze be az alkalmazás tesztelésével, ne az adapterével. Az alagúton keresztül betöltődő fájlmegosztás vagy intranetes oldal a bizonyíték arra, hogy az eszköz, a munkamenet és az útvonal összhangban van.

Kapcsolódó cikkek