A VPN-átjárójának továbbra is szüksége van módra a frissítések telepítésére

Az alagút működik mindenki számára mögötte, az átjáró továbbítja a forgalmukat, és mégis maga a gép nem tud biztonsági frissítést telepíteni. Ez a probléma szokásos formája: a továbbítási engedélyt a kliensek kapták meg, az átjáró saját kimenő kapcsolatai pedig soha nem kerültek be a tervbe. A csomagkezelő a saját socketjeit nyitja meg, az átjárótól egy olyan tároló felé, amelyet valószínűleg sehol nem nevezett meg a tűzfal-szabályzatban.

Egy átjáró lezárása helyes. Olyan alaposan lezárni, hogy már ne kapjon javításokat, más döntés, és általában véletlen.

A helyi kimenet nem kliens-továbbítás

A továbbítási szabályok azokra a csomagokra vonatkoznak, amelyek máshonnan érkeznek és az átjárón keresztül távoznak. Az átjáró saját frissítési forgalma soha nem illeszkedik rájuk; helyben keletkezik, és a kimeneti útvonalon halad. Ez a különbség magyarázza azt a hibát, amely lehetetlennek tűnik, miközben a klienshozzáférés tökéletesen működik.

Azt a szabályzati rést is magyarázza, amely túléli a teszteket, mert egy gyors ellenőrzés az alagút mögötti laptopról bizonyítja, hogy a továbbítási lánc működik, és semmit nem mond a gazdagép saját kapcsolatairól. Kezelje az átjárót két alanyként: egy routerként továbbítási lánccal és egy gazdagépként kimeneti lánccal. Mindkettőnek álláspontra van szüksége, és általában csak az egyiket írják le.

Nevezze meg a sikertelen szakaszt

A frissítési hibák különböző határokat neveznek meg, és ha valaki még az előtt egy portszabályhoz nyúl, hogy elolvasná, melyik hiúsult meg, egy délutánt veszít. Egy tárolónév, amely nem oldható fel, névfeloldási kérdés, nem átviteli kérdés.

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

A sikeres névfeloldás utáni időtúllépés az átvitelre tereli a kérdést: melyik címre, melyik portra és melyik beállított proxyra próbált valójában a csomagkezelő. A TLS-ellenőrzési hiba teljesen harmadik dolog, és azt jelenti, hogy a kapcsolat elég jól működött az egyeztetéshez. Az archívum-hitelesítésre vonatkozó panasz a negyedik szakasz, és aláírt metaadatokról szól, nem az elérhetőségről. Négy szakasz, négy különböző javítás, és a ping mindig csak egyetlen protokollt ír le, amelyet egyetlen csomagkezelő sem használ.

Olvassa el a forráslistát, mielőtt szabályt ad hozzá

Sorolja fel a tényleges forrás-URI-ket és a tényleges proxykonfigurációt, ne azokat, amelyekre emlékszik. A sima HTTP-hez írt szabály használhatatlan, ha a forrás HTTPS, és előfordulhat, hogy a shell által ismert proxy láthatatlan egy más környezetben indított szolgáltatás számára.

Az APT HTTP-átviteli dokumentációja kiterjed a környezeti és APT-specifikus proxybeállításokra, beleértve a hosztok szerinti választást is, és a HTTPS-átvitelnek saját ellenőrzési beállításai vannak. A böngésző útvonala és a csomagkezelő útvonala külön útvonalak, még ugyanazon a gépen is.

Jegyezze meg, mely címcsaládokra oldódnak fel a források. A csak IPv4-et engedélyező szabály továbbra is meghiúsul azon a gazdagépen, amelynek forrásai AAAA-rekordot részesítenek előnyben, és a hiba időszakosnak tűnik, mert attól függ, melyik válasz érkezik meg előbb.

Válasszon egy karbantartási útvonalat, és tartsa is meg

Három védhető lehetőség létezik: a karbantartási forgalom az alagúton, egy felügyelt frissítési proxyn vagy egy szűk közvetlen kivételen keresztül. Válasszon egyet tudatosan, és érje el, hogy a névfeloldó egyetértsen vele, mert az a szétválás, amelyben a nevek az egyik irányba oldódnak fel, a kapcsolatok pedig a másikba mennek, olyan hibákat okoz, amelyeket senki sem tud megmagyarázni.

Bármit is választ, nem válhat korlátlan tartalék megoldássá. Ha a közvetlen kimenő forgalom tilos, amikor az alagút nem működik, a mindent csendesen engedélyező karbantartási kivétel javításnak álcázott szabályzatváltozás. Tartsa az alagút saját végpontját és bootstrap-igényeit külön kategóriában a tárolóhozzáféréstől, mert különböző célpontokra mutatnak és különböző módokon hiúsulnak meg, így az egyik kivétel nem fedheti a másikat.

Ellenőrizzen az ellenőrzések gyengítése nélkül

A hatókört azon a tűzfalon keresztül alkalmazza, amely már birtokolja a szabályzatot, ahelyett hogy második kezelőt adna hozzá, mert egy útmutató azt használta. Ezután futtasson metaadat-frissítést és egy valódi csomagtranzakciót a karbantartott szabályzat mellett, és olvassa el a kimenetet, ne csak a kilépési állapotot.

A sikeres átvitel nem engedély az ellenőrzés lazítására. Az archívum-hitelesítés és a TLS-kiszolgáló identitása külön garanciák, és bármelyik kikapcsolása egy hiba elnémítása érdekében megváltoztatja azt, amiben bízik, nem azt, amit elérhet.

Fejezze be az alagút nélküli eset szándékos tesztelésével. Tudni, hogyan viselkedik az átjáró az alagútja nélkül, a tervezés része; kiesés közben megtudni nem az. Vegye le az alagutat, futtassa a metaadat-frissítést, és erősítse meg, hogy a gazdagép a szándékolt módon hiúsul meg, ahelyett hogy csendben visszaesne egy nyitott útvonalra. Tartsa a tároló- és proxyhitelesítő adatokat a megosztott diagnosztikán kívül, és hagyjon feljegyzést arról, ki felel a frissítési útvonalért.