A VPN-átjáró frissítése sikertelen: olvassa el a szakaszt, mielőtt megnyitja a kimenetet
A sikertelen frissítés egy szakaszt nevez meg, nem egy hiányzó portot. Rendelje az üzenetet a tulajdonosához, olvassa el a proxy útvonalát, majd döntsön szándékosan a karbantartási szabályzatról.
A biztonsági frissítések telepítésének megtagadása csak egy rossz hét választja el attól, hogy valaki más problémájává váljon, és az átjáró, amely beengedi a klienseket, a legkönnyebb hely ennek a szokásnak a kialakítására. A szokásos ok nem egy hiányzó útvonal, hanem egy hiányzó döntés: senki nem mondta meg, hogyan érje el maga a gazdagép a tárolót, amikor a kliensek továbbítása szándékosan szűk. Ezt a döntést kifejezetten meg kell hozni, és szűkebbnek kell lennie, mint a kimenő szabályzat egy délutáni kikapcsolása.
Négy szakasz, négy különböző tulajdonos
A frissítési hiba egy megnevezett szakasz, akár mondja ezt az üzenet, akár nem, és minden szakasz más tulajdonoshoz tartozik. A fel nem oldható név a feloldó kérdése. Az időtúllépést szenvedő kapcsolat a szállítás, a proxy vagy a távoli vég kérdése. A TLS-identitáshiba bizalmi kérdés, és az elutasított archív metaadatok aláírási kérdés. Négy szakasz, négy tulajdonos, és egy portszabály mindig csak egyre válaszol közülük.
| The failure text mentions | Which component owns it | What you check first | What you must not change |
|---|---|---|---|
| a name that will not resolve | the resolver policy for this host | which resolver is used, and whether its path is permitted | nothing in the firewall: no repository packet has left yet |
| a connection that times out | routing, proxy or the far end | the destination, port and proxy the manager actually attempts | the egress policy, before you know that destination |
| a TLS identity mismatch | trust configuration and the server's identity | the chain the manager is presented with | verification settings, which only hide the mismatch |
| rejected archive metadata | the repository's signing metadata | whether the source carries valid, trusted metadata | the signature check, which is not a routing question |
A ping és a névfeloldás az a két teszt, amelyhez az emberek először nyúlnak, és mindkettő olyan kérdésekre válaszol, amelyeket senki nem tett fel. Az echo válasz más protokollt használ, mint a tároló kapcsolata, és egy sikeres lekérdezés megáll a névfeloldásnál anélkül, hogy tesztelné a letöltést. Mindkettő átmehet, miközben a valódi tranzakció meghiúsul, és mindkettő meghiúsulhat az útvonaltól független okokból.
Olvassa el az útvonalat, amelyet a kezelő valóban bejár
Vizsgálja meg a beállított forrás-URI-ket és a tényleges proxy-elrendezést ahelyett, hogy bármelyiket feltételezné. Az egyszerű HTTP-hez írt szabály nem javítás, amikor a tároló HTTPS-t beszél, és a proxyt előíró szervezet már kiválasztotta az útvonalat. A csomagkezelők tiszteletben tartják a környezeti változókat és saját konfigurációjukat, és a gazdagépspecifikus beállítások felülírhatnak egy globálist. Amit egy interaktív böngésző tesz, nem feltétlenül az, amit a kezelő tesz.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyAz APT szállítási dokumentációja leírja, mely beállítások melyik URI-sémára érvényesek, és hogyan írják le a gazdagépspecifikus választásokat. Őrizze meg a parancsok kimenetét a jegy mellett, mert gyorsabban választja el a proxyproblémát a hiányzó útvonaltól, mint bármennyi pingeredmény. Jegyezze fel a pontos célt, portot és protokollt, amelyet a kezelő megpróbál, és hagyja, hogy a tűzfal módosítása ezen a feljegyzésen alapuljon, ne pedig egy hónapok alatt elavuló feltételezett tükörcímen.
Válasszon karbantartási szabályzatot, ne kivételt
Három szabályzat védhető: karbantartás az alagúton keresztül, karbantartás felügyelt frissítési proxyn keresztül, vagy karbantartás szűken engedélyezett közvetlen útvonalon keresztül. Mindegyik hozzá illő feloldó-elrendezést feltételez. Ami nem védhető, az egy kivétel, amely csendesen korlátlan tartalékúttá válik, valahányszor az alagút leesik.
Írja le a választott szabályzatot egy tulajdonossal együtt, mert a következő üzemeltető a szabályt találja meg, nem az indoklást mögötte. Az engedélyt a meglévő tűzfalon és a hálózat tulajdonosán keresztül alkalmazza, ahelyett hogy szabályokat ürítene ki vagy második szabályzatkezelőt adna hozzá egyetlen gazdagéphez. Fedje le a valódi forrás által használt címcsaládokat és szolgáltatási végpontokat, és vizsgálja felül a listát, amikor a tároló elköltözik.
Ellenőrizzen a bizalom gyengítése nélkül
A sikeres szállítás nem engedély az ellenőrzés enyhítésére: az archív hitelesítése és a TLS-kiszolgáló identitása két külön ellenőrzés, és bármelyik kikapcsolása eltüntet egy hibát, miközben megváltoztatja, mit fogad el a gazdagép. A beavatkozó proxy a hálózat tulajdonosának bizalmi döntése, nem ok arra, hogy helyben kapcsolja ki az ellenőrzést, és a tároló hitelesítő adatai nem tartoznak a megosztott diagnosztikába, mert a részletes napló a legkönnyebb hely azok kiszivárogtatására.
Fogadja el a változtatást egy ellenőrzött metaadat-lekéréssel, amelyet egy jóváhagyott csomagtranzakció követ, majd tesztelje, mi történik, amikor az alagút leesik. Az a karbantartási útvonal, amely kimaradás alatt csendesen kiszélesedik, rosszabb, mint amelyik zártan meghiúsul, és az eredménynek egy megnevezett tulajdonossal és korlátozott hatókörrel rendelkező frissítési útvonalnak kell lennie.