Három dolognak meg kell egyeznie ahhoz, hogy egy Kerio-alagút forgalmat vigyen: a kvnet interfész címének, a kliens által naplózott értéknek és annak, amit a kiszolgálói szabályzat vagy a DHCP vár. Amikor nem egyeznek, az alagút mégis hitelesít és mégis feljön, és éppen ez teszi zavaróvá a hibát. Az interfész kapcsolatonként jön létre, tehát a kézzel beállított cím ahhoz a munkamenethez tartozik, és semmi máshoz. Ez a probléma formája, a megoldás pedig egy hook, nem egy konfigurációs fájl. A többi az, hogy honnan olvassuk ki az értéket, és hol alkalmazzuk.

Miért áll vissza folyton a cím

A kvnet egy virtuális adapter, amelyet a kliens a kapcsolat indításakor hoz létre, és a végén eltávolít. Egy kézi ip link set tehát pontosan addig él, ameddig az a munkamenet, amelyre alkalmazták, és a következő kapcsolat azzal indul, amit a kliens kioszt. Egy gépen, ahol a kliens nem tudja alkalmazni a várt címet, minden újracsatlakozás ugyanazt az eltérést hozza vissza, és a bérleti vagy hozzáférési szabály ismét elutasítja az eszközt.

Ez a minta önmagában diagnosztikus. Egy alagút, amely egy munkamenetben működik és a következőben elbukik, nem hitelesítő adatok problémája, mert azok nem változnak a kapcsolatok között.

A kliensnél olvassa ki az értéket, ne az interfésznél

A Linux kliens a tárgyalás részleteit a hibakeresési naplójába írja, és a használni kívánt cím ott a kapcsolati sorozat utolsó címszerű tokenjeként jelenik meg. Hasonlítsa össze azzal, amit a kernel valóban tart, ami egy readlink távolságra van: cat /sys/class/net/kvnet/address.

Ha a kettő eltér, a kliens ismerte a helyes értéket, és nem sikerült alkalmaznia, és egy hook, amely az interfész létezése után alkalmazza, bezárja ezt a rést. Ha a napló egyáltalán nem tartalmaz címet, a probléma korábbi, és a kliens verziójához vagy a kiszolgálói profilhoz tartozik, nem egy szkripthez.

Az interfész létrejötte után alkalmazza

A NetworkManager felhasználói elhelyezhetnek egy szkriptet a diszpécser könyvtárában, és csak akkor cselekedhetnek, amikor a VPN interfész feljön. A systemd által kezelt kliens több gondosságot igényel: a szolgáltatás indításakor futó drop-in általában azelőtt aktiválódik, hogy az adapter létezne, ezért a hooknak meg kell várnia az interfészt, ahelyett hogy feltételezné. Állítsa be akkor a címet, és ha a kernel elutasítja, miközben a kapcsolat fent van, vigye le, állítsa be a címet, és hozza fel újra. Olvassa vissza a kinyert tokent egy MAC-mintán keresztül, mielőtt átadja az ip link-nek, hogy egy váratlan naplósor ne válhasson argumentummá.

Minden, ami rootként fut egy kliens naplójából, szűk tulajdonjogot érdemel: root tulajdonában lévő fájl, amelyet mások nem írhatnak, és semmilyen shell-interpoláció az ellenőrzött címen túl. Tartsa a mintát ellenőrző lépést a szkriptben. Ne engedje, hogy a napló tartalma döntse el, melyik parancs fut.

A bérletet ellenőrizze, ne a kapcsolatot

A ip -4 -o addr show dev kvnet a várt tartományban lévő címet mutasson, a ip neigh show dev kvnet az átjárót mutassa, és egy VPN mögötti szolgáltatás válaszoljon. Ezután bontsa a kapcsolatot, és csatlakozzon újra egyszer; ha a cím visszaáll, a hook rossz eseményre fut, vagy egyáltalán nem fut.

Egy interfész, amely a helyes címmel jelenik meg, és soha nem kap bérletet, a kiszolgáló oldalára mutat. Az más ellenőrzés, és általában más csapat. Erősítse meg, hogy a fiók engedélyezett, és a poolban még van cím, mielőtt újra szerkeszti a hookot.

Gondolja át a kerülő megoldást frissítés után

Egy kliens build, amely helyesen állítja be a címet, a hookját elavult érték alkalmazásában hagyja, ami egy javítás által behozott új hiba. Soha ne másoljon MAC-et másik gépről vagy fórumbejegyzésből sem; használja azt az értéket, amelyet ez a kliens ehhez a fiókhoz naplóz, és jegyezze fel a dátumot, amikor ellenőrizte.

Tartsa a szkriptet elég rövidnek, hogy egy ülésben elolvasható legyen. A naplókat elemző kerülő megoldások természetüknél fogva ideiglenesek. Azok maradnak meg, amelyeket egy jövőbeli olvasó az eredeti szál nélkül is megért.

Kapcsolódó cikkek