Vaše brána VPN stále potřebuje způsob, jak instalovat aktualizace

Tunel funguje pro všechny za ním, brána přeposílá jejich provoz, a přesto samotný stroj nedokáže nainstalovat bezpečnostní aktualizaci. To je obvyklý tvar problému: oprávnění k přeposílání dostali klienti a vlastní odchozí spojení brány se do plánu nikdy nedostala. Správce balíčků otevírá vlastní sockety, z brány, k repozitáři, který jste pravděpodobně nikde v pravidlech firewallu nepojmenovali.

Uzamknout bránu je správné. Uzamknout ji tak důkladně, že přestane dostávat záplaty, je jiné rozhodnutí, a obvykle náhodné.

Lokální výstup není přeposílání klientů

Pravidla přeposílání řídí pakety, které přicházejí odjinud a odcházejí přes bránu. Vlastní aktualizační provoz brány jim nikdy neodpovídá; vzniká lokálně a jde výstupní cestou. Ten rozdíl vysvětluje poruchu, která vypadá nemožně, zatímco přístup klientů funguje bezchybně.

Vysvětluje také mezeru v politice, která přežije testy, protože rychlá kontrola z notebooku za tunelem dokazuje, že přeposílací řetězec funguje, a nic neříká o vlastních spojeních hostitele. Berte bránu jako dva subjekty: router s přeposílacím řetězcem a hostitele s výstupním řetězcem. Oba potřebují stanovisko a obvykle se zapíše jen jedno.

Pojmenujte fázi, která selhala

Chyby aktualizace pojmenovávají různé hranice, a sáhnout po pravidle portu dřív, než přečtete, která selhala, stojí odpoledne. Název repozitáře, který se nerozřeší, je otázka pro resolver, ne otázka transportu.

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

Vypršení časového limitu po úspěšném rozlišení přesouvá otázku na transport: kterou adresu, který port a kterou nakonfigurovanou proxy správce balíčků skutečně zkusil. Selhání ověření TLS je třetí, zcela jiná věc, a znamená, že spojení fungovalo dostatečně dobře na to, aby vyjednalo parametry. Stížnost na ověřování archivu je čtvrtou fází a týká se podepsaných metadat, nikoli dostupnosti. Čtyři fáze, čtyři různá opravy, a ping vždy popisuje jen jeden protokol, který žádný správce balíčků nepoužívá.

Přečtěte si seznam zdrojů, než přidáte pravidlo

Vypište skutečné URI zdrojů a účinnou konfiguraci proxy, ne ty, které si pamatujete. Pravidlo napsané pro obyčejné HTTP je k ničemu, když je zdroj HTTPS, a proxy, kterou zná shell, může být neviditelná pro službu spuštěnou při startu s jiným prostředím.

Dokumentace transportu HTTP v APT pokrývá proxy nastavení prostředí i specifická pro APT, včetně voleb pro jednotlivé hostitele, a její transport HTTPS má vlastní nastavení ověřování. Cesta prohlížeče a cesta správce balíčků jsou oddělené cesty, i na stejném stroji.

Všimněte si, do kterých rodin se zdroje rozlišují. Pravidlo povolující jen IPv4 bude dál selhávat na hostiteli, jehož zdroje upřednostňují záznam AAAA, a chyba vypadá občasně, protože závisí na tom, která odpověď dorazí první.

Vyberte jednu cestu údržby a držte se jí

Existují tři obhajitelné možnosti: provoz údržby tunelem, přes spravovanou proxy aktualizací, nebo přes úzkou přímou výjimku. Vyberte jednu vědomě a zajistěte, aby s ní resolver souhlasil, protože rozdělení, kdy se názvy rozlišují jedním směrem a spojení jdou jiným, vytváří poruchy, které nikdo nedokáže vysvětlit.

Ať už zvolíte cokoli, nesmí se to stát neomezenou záložní cestou. Pokud je přímý odchozí provoz zakázán, když je tunel mimo provoz, výjimka pro údržbu, která tiše povoluje vše, je změna politiky převlečená za opravu. Udržujte vlastní koncový bod tunelu a potřeby bootstrapu v samostatné kategorii od přístupu k repozitářům, protože ukazují na různé cíle a selhávají různými způsoby, takže jedna výjimka nemůže pokrýt druhou.

Ověřujte, aniž byste oslabili kontroly

Uplatněte rozsah přes firewall, který politiku už vlastní, místo abyste přidávali druhého správce, protože ho použil jeden návod. Poté spusťte obnovu metadat a jednu skutečnou transakci s balíčky podle udržované politiky a čtěte výstup, ne jen návratový kód.

Úspěšný transport není povolení uvolnit ověřování. Ověřování archivu a identita serveru TLS jsou samostatné záruky a vypnutí kterékoli z nich, aby utichla chyba, mění to, čemu důvěřujete, ne to, kam se dostanete.

Na závěr vědomě otestujte případ bez tunelu. Vědět, jak se brána chová bez svého tunelu, patří k návrhu; zjistit to během výpadku ne. Vypněte tunel, spusťte obnovu metadat a potvrďte, že hostitel selže zamýšleným způsobem, místo aby tiše spadl zpět na otevřenou cestu. Držte přihlašovací údaje k repozitářům a proxy mimo sdílenou diagnostiku a zanechte poznámku, kdo vlastní cestu aktualizací.