VPN-végpontok engedélyezési listája: az elfelejtett DNS-frissítés

A vpn.example.com beírása egy tűzfal-kivételbe olyan, mintha DNS-előfizetnénk. Általában betöltéskor történik egy fordítás, utána a szabály címeket tart, és semmi nem frissíti őket. Két összetevő osztozik most a munkán: a válaszoló feloldó és a tároló tűzfal. A legtöbb végponti kiesés ott kezdődik, ahol ezt az átadást soha nem tervezték meg.

Egy szabályban szereplő gépnév nem élő előfizetés

Egyes eszközök a konfiguráció betöltésekor oldják fel a nevet; mások megtartanak egy gépnevet, és saját ütemtervük szerint oldják fel újra; megint mások csak címeket fogadnak el. A látható konfiguráció ritkán mondja meg, melyik. A dokumentációs példák általában a betöltési esetet feltételezik, ezért lepi meg az embereket a különbség migráció közben. Olvasd el az implementáció viselkedését, mielőtt feltételezed, hogy észrevesznek egy címváltozást, mert egy elavult engedélyezési lista pontosan úgy néz ki, mint egy működő amíg a végpont el nem mozdul.

Egy szabály, amely a helyes gazdagépet nevezi meg, továbbra is engedélyezheti a rossz címet. Ez a rés a mítosz, nem elírás.

A gyorsítótár TTL-je nem a tűzfalad időzítője

A DNS-rekordoknak élettartamuk van, és a feloldók addig az időtartamig gyorsítótárazzák a válaszokat. A DNS-specifikáció meghatározza ezt a gyorsítótárazási viselkedést, de DNS-adatokat szabályoz, nem egy tűzfal külön címtárát. Egy rövid TTL nem hoz létre frissítési feladatot ott, ahol nincs. A gyorsítótárazás több rétegen is történik, ezért lehet, hogy a terminál által látott válasz nem az, amelyet a tűzfal látott.

Tegyél fel három kérdést a tényleges terméknek: mikor old fel, hol tárolja az eredményt, és mi indít frissítést. Ha a válasz csak indításkor érvényes, egy hosszú életű munkamenet túlélheti azt a címet, amelyre beengedték.

dig +short vpn.example.com
resolvectl query vpn.example.com

Tervezd a frissítést és a hibát egyetlen szabályként

A karbantartott kivételhez egyértelmű válaszok kellenek: mi indít frissítést, mielőtt az ügyfél új címet választ, hogyan változik az engedélyezett halmaz széles ideiglenes ablak megnyitása nélkül, és mikor távolítják el az elavult bejegyzéseket. Írd ezeket a válaszokat a szabály mellé.

Válaszd meg szándékosan a hiba viselkedését. A régi cím megtartása megőrizhet egy munkamenetet, és elavult engedélyt hagyhat; a halmaz kiürítése akadályozhatja a helyreállítást. Egyik sem lehet egy sikertelen lekérdezés véletlen eredménye. Írd a választott viselkedést a runbookba, hogy a következő üzemeltető ne improvizáljon nyomás alatt.

Tartsd szűken a bootstrap DNS-t is. A nyilvános feloldó feltétel nélküli kivétele közvetlen DNS-út mindenhez, amire illeszkedik, nem csak a végpont nevéhez.

A végpont változását bizonyítsd, ne az első kapcsolatot

Használd az ügyfél támogatott kezelőjét, ha az már összehangolja a feloldást és a blokkolást. Egy hely által kezelt PF-gazdagépen tartsd meg a hely tulajdonjogát és helyreállítási tervét, ahelyett hogy egy más életciklus-viselkedésű platform gépnévtábla-szintaxisát másolnád.

Egy jóváhagyott, ártalmatlan teszttel hasonlítsd össze az ügyfél által választott címet az aktív engedélyezett halmazzal egy ellenőrzött változás előtt és után. Fedd le a sikertelen lekérdezést, egy már nem érvényes bejegyzés törlését, és ahol támogatott, egy másik címcsaládot. A szánt alagútnak helyre kell állnia, miközben a független közvetlen forgalom a szabályzat alatt marad. Egy sikeres első kapcsolat csak azt bizonyítja, hogy a kezdeti fordítás véletlenül helyes volt.