Jūsų VPN šliuzui vis dar reikia būdo įdiegti atnaujinimus
Užrakintas šliuzas vis tiek turi pasiekti savo saugyklas. Išsiaiškinkite, kuris etapas nepavyko, o tada leiskite būtent tą kelią, o ne atverkite išeinantį srautą.
Tunelis veikia visiems už jo esantiems, šliuzas perduoda jų srautą, ir vis dėlto pati mašina negali įdiegti saugos atnaujinimo. Tai įprasta problemos forma: perdavimo leidimas buvo suteiktas klientams, o paties šliuzo išeinantys ryšiai niekada nebuvo įtraukti į planą. Paketų tvarkyklė atidaro savo lizdus, iš šliuzo, į saugyklą, kurios tikriausiai niekur nepavadinote ugniasienės taisyklėse.
Užrakinti šliuzą yra teisinga. Užrakinti jį taip kruopščiai, kad jis nustotų gauti pataisas, yra kitas sprendimas, ir dažniausiai atsitiktinis.
Vietinė išeiga nėra klientų perdavimas
Perdavimo taisyklės valdo paketus, kurie atvyksta iš kitur ir išeina pro šliuzą. Paties šliuzo atnaujinimo srautas joms niekada neatitinka; jis sukuriamas vietoje ir eina išėjimo keliu. Šis skirtumas paaiškina gedimą, kuris atrodo neįmanomas, kol klientų prieiga veikia nepriekaištingai.
Jis taip pat paaiškina politikos spragą, kuri išgyvena testus, nes greitas patikrinimas iš nešiojamojo kompiuterio už tunelio įrodo, kad perdavimo grandinė veikia, ir nieko nesako apie paties pagrindinio kompiuterio ryšius. Traktuokite šliuzą kaip du subjektus: maršrutizatorių su perdavimo grandine ir pagrindinį kompiuterį su išėjimo grandine. Abiem reikia nuomonės, ir dažniausiai užrašoma tik viena.
Įvardykite nepavykusį etapą
Atnaujinimo klaidos įvardija skirtingas ribas, o griebimasis už prievado taisyklės prieš perskaičius, kuri nepavyko, kainuoja popietę. Saugyklos pavadinimas, kuris neišsprendžiamas, yra resolver klausimas, o ne transporto klausimas.
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
Skirtasis laikas po sėkmingo išsprendimo perkelia klausimą į transportą: kurį adresą, kurį prievadą ir kurį sukonfigūruotą tarpinį serverį paketų tvarkyklė iš tikrųjų bandė. TLS patikros klaida yra trečias, visiškai kitas dalykas, ir reiškia, kad ryšys veikė pakankamai gerai, kad galėtų derėtis. Skundas dėl archyvo autentifikavimo yra ketvirtas etapas, ir jis susijęs su pasirašytais metaduomenimis, o ne su pasiekiamumu. Keturi etapai, keturi skirtingi taisymai, o ping visada aprašo tik vieną protokolą, kurio nenaudoja jokia paketų tvarkyklė.
Perskaitykite šaltinių sąrašą prieš pridėdami taisyklę
Išvardykite tikruosius šaltinių URI ir veikiančią tarpinio serverio konfigūraciją, o ne tas, kurias prisimenate. Taisyklė, parašyta paprastam HTTP, yra nenaudinga, kai šaltinis yra HTTPS, o tarpinis serveris, kurį žino apvalkalas, gali būti nematomas paslaugai, paleistai įkrovimo metu su kita aplinka.
APT HTTP transporto dokumentacija apima aplinkos ir APT būdingus tarpinio serverio nustatymus, įskaitant pasirinkimus pagal pagrindinį kompiuterį, o jos HTTPS transportas turi savo patikros nustatymus. Naršyklės kelias ir paketų tvarkyklės kelias yra atskiri keliai, net toje pačioje mašinoje.
Atkreipkite dėmesį, į kokias šeimas šaltiniai išsprendžiami. Taisyklė, leidžianti tik IPv4, toliau nepavyks pagrindiniame kompiuteryje, kurio šaltiniai teikia pirmenybę AAAA įrašui, o klaida atrodo su pertraukomis, nes priklauso nuo to, kuris atsakymas atvyksta pirmas.
Pasirinkite vieną priežiūros kelią ir jo laikykitės
Yra trys pateisinami variantai: priežiūros srautas per tunelį, per valdomą atnaujinimų tarpinį serverį arba per siaurą tiesioginę išimtį. Pasirinkite vieną sąmoningai ir pasirūpinkite, kad resolver sutiktų, nes suskaidymas, kai vardai išsprendžiami viena kryptimi, o ryšiai eina kita, sukuria gedimus, kurių niekas negali paaiškinti.
Kad ir ką pasirinktumėte, tai neturi tapti neribotu atsarginiu variantu. Jei tiesioginis išeinantis srautas draudžiamas, kai tunelis neveikia, priežiūros išimtis, kuri tyliai leidžia viską, yra politikos pakeitimas, užmaskuotas kaip pataisa. Laikykite paties tunelio galinį tašką ir bootstrap poreikius atskiroje kategorijoje nuo prieigos prie saugyklų, nes jie nurodo skirtingas paskirties vietas ir nepavyksta skirtingais būdais, todėl viena išimtis negali apimti kitos.
Tikrinkite nesusilpnindami patikrų
Taikykite apimtį per ugniasienę, kuri jau valdo politiką, o ne pridėkite antrą tvarkyklę, nes vienas vadovas ją naudojo. Tada paleiskite metaduomenų atnaujinimą ir vieną tikrą paketų operaciją pagal palaikomą politiką, ir skaitykite išvestį, o ne vien išėjimo būseną.
Sėkmingas transportas nėra leidimas sušvelninti patikrą. Archyvo autentifikavimas ir TLS serverio tapatybė yra atskiros garantijos, o išjungus bet kurią iš jų, kad nutiltų klaida, keičiasi tai, kuo pasitikite, o ne tai, ką galite pasiekti.
Užbaikite sąmoningai išbandydami atvejį be tunelio. Žinoti, kaip šliuzas elgiasi be savo tunelio, yra projekto dalis, sužinoti tai per triktį – ne. Išjunkite tunelį, paleiskite metaduomenų atnaujinimą ir patvirtinkite, kad pagrindinis kompiuteris nepavyksta numatytu būdu, o ne tyliai grįžta į atvirą kelią. Laikykite saugyklų ir tarpinio serverio kredencialus už bendros diagnostikos ribų ir palikite pastabą, kas atsako už atnaujinimo kelią.