Kontrola linuxového rozhraní VPN pomocí ip link, vrstvu po vrstvě
Příznaky a čítače popisují jen jednu vrstvu. Přečtěte si odkaz, pak čítače, pak adresy a trasy, než usoudíte, že je tunel rozbitý.
Ikona klienta hlásí připojeno, rozhraní existuje a aplikace přesto ničeho nedosáhne. Taková kombinace je běžná, protože virtuální rozhraní může zůstat přítomné, zatímco jeho vzdálený protějšek, adresy nebo trasy chybí. ip link je správný první nástroj a zároveň ten, u kterého se nejčastěji přečte víc, než skutečně říká. Příznaky a čítače popisují jednu vrstvu a vrstvy nad nimi selhávají nezávisle. Je to také nástroj, který lidé citují, když chtějí dokázat, že tunel běží, tedy právě tvrzení, které sám o sobě nepodloží.
Přečtěte si rozhraní dřív než ikonu
Začněte s ip -details link show dev tun0 jak je popsáno v manuálu k ip-link, a místo obvyklého názvu dosaďte rozhraní, které váš klient skutečně vlastní. Příznaky, typ, MTU a identita rozhraní jsou užitečná pozorování. Formulace stavu virtuálního rozhraní se nemusí chovat jako indikace nosného signálu fyzického kabelu, proto berte UP jako tvrzení o rozhraní, ne o tunelu.
Tento rozdíl vysvětluje nejmatoucí případ: rozhraní, které přetrvává, zatímco se vzdálená strana znovu připojuje nebo je nedostupná.
Nastavení trvalosti může spojení udržovat právě proto, aby ho opakované připojení znovu nestavělo, což znamená, že přítomnost není zdraví.
Přidejte čítače a požadavek, který by je měl použít
Použijte podporovaný pohled na statistiky ip -s link show dev tun0 a poznamenejte si počty paketů a bajtů v obou směrech. Pak vygenerujte neškodný požadavek, který by měl rozhraním projít, a porovnejte příslušný směr. Požadavek, který šel přímou trasou jiné aplikace, tyto čítače nepohne, a o to v tomto cvičení jde.
Pokud se čítač odesílání hýbe a čítač příjmu ne, paket odešel a nic se nevrátilo. To je jiný problém než rozhraní, které nikdy nic nepřeneslo. Pokud se hýbou oba čítače a aplikace stále selhává, závada je nad rozhraním, což je pokrok, ne slepá ulička.
Změřte to dvakrát, jednou před a jednou po, místo abyste věřili jedinému snímku.
Adresy a trasy jsou samostatné kroky
Spojení může existovat bez prefixu, konfigurace překladače nebo trasy, kterou aplikace potřebuje. Zkontrolujte adresu pomocí ip address show dev tun0, pak zkontrolujte, kterou trasu by cíl zvolil, pomocí ip route get pro skutečný cíl. Tato tři pozorování odpovídají na tři různé otázky a jen to poslední se týká předávání.
U IPsec mohou hrát roli i bezpečnostní politika a stav asociace a ne každý návrh IPsec se objeví jako jednoduché rozhraní tun. Hledat zařízení tun, které nikdy nemělo existovat, je rychlá cesta ke špatnému závěru.
Zapište přesný název, jmenný prostor a čas u každého výstupu, který si ponecháte, protože stejně vypadající název v jiném kontejneru nebo obnovené relaci představuje úplně jiný kontext.
Nemažte to, co jste neidentifikovali
Neznámé rozhraní není automaticky zastaralé. Než cokoli odstraníte, zjistěte jeho vlastníka, a pokud je odstranění skutečně zamýšlené, použijte dokumentované rozebrání klienta nebo spravovanou konfiguraci. Smazat živý tunel, abyste viděli, co se stane, je test, který odpovídá na otázku, kterou nikdo nepoložil.
Pokud rozhraní patří kontejnerovému běhovému prostředí nebo síťovému jmennému prostoru, který jste nevytvořili, je vlastník vzdálený jeden příkaz a stojí za to ho najít jako první.
Tato opatrnost platí i pro ip link set down, což vypadá vratně a často není.
Co by vám kontrola měla nechat
Dobrá kontrola končí čtyřmi fakty: názvem a jmenným prostorem rozhraní, jeho příznaky a MTU, deltou čítačů ze skutečného požadavku a trasou a adresou, kterou aplikace opravdu potřebuje. Když jsou zapsané, je další krok zřejmý a patří konkrétní vrstvě. Bez nich je každá další změna odhad s plánem návratu.
Porovnejte tyto čtyři fakty se stejnými čtyřmi z funkční relace. Pokud název a jmenný prostor sedí, ale delta čítačů je nulová, požadavek se k tunelu nikdy nedostal. Pokud je delta zdravá a trasa ukazuje jinam, tunel je v pořádku a směrování ne. Právě toto srovnání mění hromadu výstupu v rozhodnutí.
Uchovejte výstup u ticketu, protože pozdější srovnání má smysl jen tehdy, když vidíte, co se změnilo.
Pak uzavřete smyčku tím, že aplikaci znovu otestujete, protože rozhraní nebylo to, na čem uživateli záleželo.