VPN-gatewaysi tarvitsee edelleen tavan asentaa päivityksiä

Tunneli toimii kaikille sen takana, gateway välittää heidän liikenteensä, ja silti kone itse ei voi asentaa tietoturvapäivitystä. Tämä on ongelman tavallinen muoto: välitysoikeus myönnettiin asiakkaille, eikä gatewayn omia lähteviä yhteyksiä koskaan sisällytetty suunnitelmaan. Paketinhallinta avaa omat pistokkeensa gatewaysta repositorioon, jota et todennäköisesti ole nimennyt missään palomuurikäytännössä.

Gatewayn lukitseminen on oikein. Sen lukitseminen niin perusteellisesti, että se lakkaa vastaanottamasta korjauksia, on toinen päätös, ja yleensä vahingossa tehty.

Paikallinen lähtevä liikenne ei ole asiakasvälitystä

Välityssäännöt koskevat paketteja, jotka saapuvat muualta ja poistuvat gatewayn kautta. Gatewayn oma päivitysliikenne ei koskaan osu niihin; se syntyy paikallisesti ja kulkee lähtöpolkua. Tämä ero selittää vian, joka tuntuu mahdottomalta, vaikka asiakkaiden pääsy toimii täydellisesti.

Se selittää myös käytäntöaukon, joka kestää testit, koska nopea tarkistus tunnelin takana olevasta kannettavasta todistaa välitysketjun toimivan eikä kerro mitään isännän omista yhteyksistä. Käsittele gatewayta kahtena subjektina: reitittimenä, jolla on välitysketju, ja isäntänä, jolla on lähtöketju. Molemmat tarvitsevat kannan, ja yleensä vain toinen niistä kirjataan.

Nimeä vaihe, joka epäonnistui

Päivitysvirheet nimeävät eri rajoja, ja porttisääntöön tarttuminen ennen lukemista, mikä niistä epäonnistui, maksaa iltapäivän. Repositorion nimi, joka ei ratkea, on resolverikysymys, ei kuljetuskysymys.

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

Aikakatkaisu onnistuneen nimeämisen jälkeen siirtää kysymyksen kuljetukseen: mitä osoitetta, mitä porttia ja mitä määritettyä välityspalvelinta paketinhallinta todella yritti. TLS-varmennusvirhe on täysin kolmas asia, ja se tarkoittaa, että yhteys toimi tarpeeksi hyvin neuvotteluun. Valitus arkiston todennuksesta on neljäs vaihe, ja se koskee allekirjoitettua metatietoa eikä tavoitettavuutta. Neljä vaihetta, neljä erilaista korjausta, ja ping kuvaa aina vain yhtä protokollaa, jota mikään paketinhallinta ei käytä.

Lue lähdeluettelo ennen säännön lisäämistä

Luettele todelliset lähde-URI:t ja tehokas välityspalvelinasetus sen sijaan, että luottaisit muistamiisi. Tavalliselle HTTP:lle kirjoitettu sääntö on hyödytön, kun lähde on HTTPS, ja komentotulkin tuntema välityspalvelin voi olla näkymätön eri ympäristössä käynnistetylle palvelulle.

APT:n HTTP-kuljetuksen dokumentaatio kattaa ympäristö- ja APT-kohtaiset välityspalvelinasetukset, mukaan lukien valinnat isäntäkohtaisesti, ja sen HTTPS-kuljetuksella on omat varmennusasetuksensa. Selain kulkee yhtä polkua ja paketinhallinta toista, jopa samalla koneella.

Huomaa, mihin osoiteperheisiin lähteet ratkeavat. Sääntö, joka sallii vain IPv4:n, epäonnistuu edelleen isännällä, jonka lähteet suosivat AAAA-tietuetta, ja virhe vaikuttaa satunnaiselta, koska se riippuu siitä, kumpi vastaus saapuu ensin.

Valitse yksi ylläpitopolku ja pidä siitä kiinni

Kolme puolustettavaa vaihtoehtoa on olemassa: ylläpitoliikenne tunnelin kautta, hallitun päivitysvälityspalvelimen kautta tai kapean suoran poikkeuksen kautta. Valitse yksi tarkoituksella ja saa resolveri samaan mieltä, koska jako, jossa nimet ratkeavat yhteen suuntaan ja yhteydet menevät toiseen, tuottaa vikoja, joita kukaan ei osaa selittää.

Mitä ikinä valitsetkin, siitä ei saa tulla rajoittamatonta varavaihtoehtoa. Jos suora lähtevä liikenne on kielletty, kun tunneli on alhaalla, ylläpitopoikkeus, joka hiljaisesti sallii kaiken, on korjaukseksi naamioitu käytäntömuutos. Pidä tunnelin oma päätepiste ja käynnistystarpeet erillisenä luokkana repositorioiden käytöstä, koska ne osoittavat eri kohteisiin ja epäonnistuvat eri tavoin, joten yksi poikkeus ei voi kattaa toista.

Varmista heikentämättä tarkistuksia

Kohdista laajuus palomuurin kautta, joka jo omistaa käytännön, sen sijaan että lisäisit toisen hallinnan, koska yksi opas käytti sitä. Aja sitten metatietojen päivitys ja yksi todellinen pakettitapahtuma ylläpidetyn käytännön alla, ja lue tuloste eikä pelkkä poistumistila.

Onnistunut kuljetus ei ole lupa löysentää varmennusta. Arkiston todennus ja TLS-palvelimen identiteetti ovat erillisiä takeita, ja jommankumman poistaminen käytöstä virheen vaientamiseksi muuttaa sitä, mihin luotat, ei sitä, mihin pääset.

Lopuksi testaa tarkoituksella tilanne ilman tunnelia. Tieto siitä, miten gateway käyttäytyy ilman tunneliaan, kuuluu suunnitteluun, sen löytäminen keskeytyksen aikana ei. Laske tunneli alas, aja metatietojen päivitys ja vahvista, että isäntä epäonnistuu tarkoittamallasi tavalla sen sijaan, että putoaisi hiljaa avoimelle polulle. Pidä repositorioiden ja välityspalvelimen tunnukset poissa jaetuista diagnostiikoista ja jätä muistiinpano, joka nimeää päivityspolun omistajan.