Egyszerűbb-e a teljes alagút egy hosszú osztott alagút listánál?

Egy osztott alagút lista három alkalmazással indul, és végül a gép nagy részét lefedi, és minden új sor valakinek a kivétele. Ezen a ponton a lista csendesen lépésekkel megtoldott alapértelmezéssé vált. A teljes alagút megfordítja az elrendezést: minden az alagútba kerül, hacsak egy dokumentált kivétel mást nem mond. Hogy ez egyszerűbb-e, az átjárótól és a helyi szolgáltatásoktól függ, amelyeket elrontana.

Kezdje azzal, hogy megszámolja a karbantartott szabályokat

Számolja meg a bejegyzéseket, majd számolja meg, hánynak van nevesített tulajdonosa és utolsó ellenőrzési dátuma. A második szám számít, mert azt a kivételt, amelynek nincs gazdája, nem lehet értékelni, amikor a szoftvert, amelyre hivatkozik, átnevezik vagy lecserélik. A végrehajtható fájl útvonalához kötött szabályok frissítés után csendesen megszűnnek működni, és a hiba instabil VPN-nek látszik, nem elavult szabálynak. Írja le a listát, mielőtt véleményt alkot róla.

Minden bejegyzésnek három kérdésre kell válaszolnia: mi törik el nélküle, ki döntött erről, és hogyan venné észre, hogy az ok lejárt. Azok a bejegyzések, amelyek mindháromra nem tudnak válaszolni, törlésre, nem migrálásra jelöltek, és az első törlésük őszintévé teszi a későbbi összehasonlítást.

Ha a legtöbb bejegyzés a forgalom nagy részét irányítja, már teljes alagutat futtat, plusz karbantartási teherrel. A döntés ekkor arról szól, hol lakik az alapértelmezés, nem arról, hogy legyen-e egyáltalán.

Ellenőrizze, hogy az átjáró elbírja-e az alapértelmezést

A teljes alagút minden csomagot egyetlen eszközre visz, ami egyszerre változtatja meg az eszköz processzor terhelését, a conntrack táblát, a címfordítást és a felfelé irányuló sávszélesség igényét. Egy átjáró, amely néhány belső alhálózatot kényelmesen kiszolgált, lehet, hogy nem egy felhasználó teljes böngészésére lett méretezve. Nézze a várható legnagyobb egyidejű munkamenet-számot, ne az átlagot, mert a csúcs törik el először.

ip -s link show dev tun0
conntrack -C
ss -s

Mérje ugyanazt a terhelést a változás előtt és után, ahelyett hogy specifikációkból következtetne. Egyetlen délután rendes használat egy gépen megmutatja, hogy az átjáró közel van-e egy határhoz, és ez semmibe sem kerül ahhoz képest, hogy hétfő reggel fedezze fel.

Ellenőrizze az útvonal MTU-ját is végponttól végpontig, mert a teljes alapértelmezés minden alkalmazást kitesz az alagút maximális csomagméretének. Az alagúton kívül működő alkalmazások most olyan töredezési viselkedéstől függhetnek, amelyre soha nem kellett gondolnia.

Erősítse meg, hogy a helyi szolgáltatások és a privát DNS még működnek

Sorolja fel, minek kell helyben maradnia protokoll szerint, nem alkalmazásnév szerint: felderítő protokollok nyomtatókhoz és kijelzőkhöz, okosotthon-híd, útválasztó kezelőlapja, helyi fejlesztői kiszolgáló, amelyet olyan névvel érnek el, amely csak a helyi hálózaton oldódik fel. Ezek eltörnek, amikor az alapértelmezett útvonal elkezd egy alagútba mutatni, és csendesen törnek el, mert semmi sem naplóz hibát az ügyfélnél.

A privát DNS a másik függőség. Ha a belső neveket korábban az alagút feloldója oldotta fel, semmi sem változik; ha helyben oldódtak fel, a teljes alapértelmezésnek el kell vinnie őket egy olyan feloldóhoz, amely ismeri a zónákat. A változás után teszteljen egy belső és egy nyilvános nevet, ahelyett hogy feltételezné, hogy a feloldólista túlélte.

Írja a helyi kivételeket abba a profilba, amelyhez tartoznak. A csak valaki emlékezetében tartott kivétel az első, amit a következő migrálás elveszít.

Migráljon egy profilt, és ellenőrizze a határokat

A profilt a saját konfigurációján keresztül módosítsa, ahelyett hogy új alapértelmezést rétegezne a korábbi kísérletek után maradt kézi útvonalakra. Ezek a maradék útvonalak a szokásos oka annak a migrálásnak, amely működni látszik, és egy nappal később következetlenül viselkedik. Tartsa elérhetően a régi profilt, hogy a visszaállás választás legyen, ne újjáépítés.

Utána két határt külön ellenőrizzen: hogy a nyilvános és a privát célok is működnek, és hogy a nem kívánt forgalom nem hagyja el az alagutat. Egy sikeres oldalbetöltés az elsőt bizonyítja, a másodikról semmit sem mond.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Ismételje meg az ellenőrzést újracsatlakozás után és kiesés után, mert a kiesés alatt forgalmat blokkoló kapcsoló más tulajdonság, mint egy útvonal, amely utána helyesen áll helyre. Az egyszerűbb terv az, amelynek valódi lefedettségét még el tudja magyarázni, miután egy alkalmazás vagy egy hálózat megváltozik.