Útvonalválasztó VPN felügyelete egyetlen állapotjelző lámpára sem hagyatkozva

A státuszoldal azt írja, hogy csatlakozva, a lámpa zöld, és az iroda mégsem éri el a fájlszervert. E tények egyike az alagútról szól, a másik a rajta átvezető útvonalról. Mindkettő felügyelete a különbség egy cselekvésre alkalmas riasztás és egy megszokottan figyelmen kívül hagyott riasztás között.

Öt ellenőrzés, sorrendben, a peertől kifelé.

1. ellenőrzés: peer- vagy asszociációs állapot

Minden protokoll a saját állapotát tárja fel. A WireGuard a legutóbbi kézfogást és a peer-enkénti átviteli számlálókat mutatja a wg show segítségével. Az OpenVPN a munkamenet állapotát az állapotfájljába vagy felügyeleti interfészére írja, az IPsec pedig biztonsági asszociációkat tár fel olyan eszközökkel, mint a ipsec statusall. A csapda az, hogy az időbélyeget ítéletként olvassuk: egy tétlen WireGuard-peer, amelynek nincs mit küldenie, nem fog nemrég kézfogást végrehajtani, és ez nem kiesés.

Hasonlítsa össze az időbélyeget a várható forgalommal és a keepalive-beállításokkal, mielőtt bárkit riasztana.

2. ellenőrzés: a kiválasztott útvonal

Létezhet alagút-interfész úgy, hogy semmi nem irányul bele. Ellenőrizze a továbbítási táblát az Önt érdeklő célállomásra, ne az alagút saját alhálózatára. Ha az előtag hiányzik, vagy máshová mutat, a peer állapota lényegtelen.

Ez az ellenőrzés elkapja azt a hibát, amelyet egy állapotjelző lámpa soha nem mutat.

Egy hasznos második ellenőrzés a forrás címet is összehasonlítja. A ip route get 10.20.5.10 visszaadja a következő ugrást, az interfészt és az előnyben részesített forrást, és egy rossz forrás elég ahhoz, hogy a távoli végén megtörje a visszatérő forgalmat. Jegyezze fel a várt hármast egyszer, majd riasszon, amikor bármelyik elem megváltozik. Ez az egyetlen sor elkapja a NAT-változásokat, az interfész-ingadozásokat és a házirend-alapú útválasztás hibáit.

3. ellenőrzés: engedélyezett alkalmazásútvonal

Próbáljon ki valamit, ami a tényleges követelményt képviseli. Az útválasztóból induló ping az útválasztó saját címéről és házirendjéről indul, amely eltérhet a továbbított LAN-forgalomtól, és sok gazdagép korlátozza az ICMP-t. Ha a követelmény privát szolgáltatás, tesztelje azt a szolgáltatást a valódi portján.

Tartsa szerényen a próba mennyiségét. A felügyeleti hurok nem válhat azzá a forgalommá, amelyet mér.

4. ellenőrzés: mi változott és mikor

Korrelálja a WAN-változásokat, a kulcsmegújításokat, az útvonal-visszavonásokat és az alkalmazáshibákat egy idővonalon. Különböztesse meg az alagút hibáját egy tartalék útvonaltól, amely csendben helyreállítja a szokásos internetelérést, mert mindkettő azonos felhasználói jelentéseket és ellentétes diagnózisokat ad. Az időzóna-hibák megfordítják a sorrendet, ezért az összehasonlítás előtt normalizáljon. Az idővonal az, ami négy ellenőrzést okozattá tesz.

A naplókat az átmenetekhez őrizze meg, nem a hasznos terheléshez.

5. ellenőrzés: a riasztás nevezze meg a határt

A VPN leállt üzenetű riasztás az esetek felében rossz helyre küld valakit. Az, amelyik azt mondja, hogy a peer kézfogása tizenkét perce elavult, a 10.20.0.0/16 útvonal hiányzik, vagy a 445-ös portra irányuló próba meghiúsul, konkrét ellenőrzésre mutat.

Vezessen üzemeltetési számlálókat ahelyett, hogy hasznos terheléseket böngészne. A számlálók megválaszolják a felügyeleti kérdést anélkül, hogy szükségtelen tartalmat gyűjtenének.

És hagyja, hogy a feladatátvételi házirend döntse el, mi történik ezután. A felügyeletnek azonosítania kell, melyik határ hibázott, nem pedig széles megkerülést engedélyeznie minden alkalommal, amikor egy próba meghiúsul. Az OpenVPN 2.6 kézikönyve dokumentálja az állapotfájlt és a felügyeleti interfészt, amelyek az első ellenőrzést szkriptelhetővé teszik.