Ձեր VPN դարպասին դեռ պետք է թարմացումներ տեղադրելու ուղի
Կողպված դարպասը միևնույն է պետք է հասնի իր պահոցներին։ Պարզեք, թե որ փուլն է ձախողվել, ապա թույլատրեք հենց այդ ուղին՝ ելքային տրաֆիկը բացելու փոխարեն։
Թունելը աշխատում է նրա հետևում գտնվող բոլորի համար, դարպասը փոխանցում է նրանց տրաֆիկը, և այնուամենայնիվ ինքը՝ մեքենան, չի կարող տեղադրել անվտանգության թարմացում։ Սա խնդրի սովորական ձևն է՝ փոխանցման թույլտվությունը տրվել է հաճախորդներին, իսկ դարպասի սեփական ելքային միացումները երբեք չեն ներառվել պլանում։ Փաթեթների կառավարիչը բացում է իր սեփական սոկետները, դարպասից, դեպի պահոց, որը դուք, հավանաբար, ոչ մի տեղ չեք անվանել firewall-ի քաղաքականության մեջ։
Դարպասը կողպելը ճիշտ է։ Այն այնքան մանրակրկիտ կողպելը, որ այն դադարի կարկատաններ ստանալ, այլ որոշում է, և սովորաբար պատահական։
Տեղական ելքը հաճախորդների փոխանցում չէ
Փոխանցման կանոնները կարգավորում են այն փաթեթները, որոնք գալիս են այլ տեղից և դուրս են գալիս դարպասով։ Դարպասի սեփական թարմացման տրաֆիկը երբեք չի համապատասխանում դրանց. այն ստեղծվում է տեղում և անցնում է ելքի ուղով։ Այդ տարբերությունը բացատրում է անհնար թվացող խափանումը, մինչ հաճախորդների մուտքը կատարյալ աշխատում է։
Այն նաև բացատրում է քաղաքականության բաց, որը վերապրում է թեստերը, որովհետև թունելի հետևում գտնվող նոթբուքից արված արագ ստուգումը ապացուցում է, որ փոխանցման շղթան աշխատում է, և ոչինչ չի ասում հենց հոսթի միացումների մասին։ Դարպասին վերաբերվեք որպես երկու սուբյեկտի՝ երթուղիչ՝ փոխանցման շղթայով, և հոսթ՝ ելքի շղթայով։ Երկուսին էլ պետք է կարծիք, և սովորաբար գրվում է միայն մեկը։
Անվանեք ձախողված փուլը
Թարմացման սխալները անվանում են տարբեր սահմաններ, և պորտի կանոնին դիմելը նախքան կարդալը, թե որն է ձախողվել, արժենա մի կես օր։ Պահոցի անունը, որը չի լուծվում, resolver-ի հարց է, ոչ թե տրանսպորտի հարց։
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
Ժամանակի սպառումը հաջող որոնումից հետո հարցը տեղափոխում է տրանսպորտ՝ թե կոնկրետ որ հասցեն, որ պորտը և որ կազմաձևված վստահված սերվերը փորձել է փաթեթների կառավարիչը։ TLS-ի ստուգման ձախողումը երրորդ, բոլորովին այլ բան է, և նշանակում է, որ կապն աշխատել է բավական լավ՝ բանակցելու համար։ Արխիվի վավերացման վերաբերյալ բողոքը չորրորդ փուլն է, և այն վերաբերում է ստորագրված մետատվյալներին, այլ ոչ թե հասանելիությանը։ Չորս փուլ, չորս տարբեր վերանորոգում, և ping-ը միշտ նկարագրում է միայն մեկ արձանագրություն, որը ոչ մի փաթեթների կառավարիչ չի օգտագործում։
Կարդացեք աղբյուրների ցանկը նախքան կանոն ավելացնելը
Թվարկեք աղբյուրների իրական URI-ները և գործող վստահված սերվերի կարգավորումը, ոչ թե նրանք, որոնք հիշում եք։ Պարզ HTTP-ի համար գրված կանոնն անօգուտ է, երբ աղբյուրը HTTPS է, և վստահված սերվերը, որը shell-ը գիտի, կարող է անտեսանելի լինել մեկ այլ միջավայրով գործարկվող ծառայության համար։
APT-ի HTTP տրանսպորտի փաստաթուղթը ընդգրկում է միջավայրի և APT-ին բնորոշ վստահված սերվերի կարգավորումները, ներառյալ ընտրությունը յուրաքանչյուր հոսթի համար, և նրա HTTPS տրանսպորտն ունի իր ստուգման կարգավորումները։ Զննարկիչի ուղին և փաթեթների կառավարչի ուղին առանձին ուղիներ են, նույնիսկ նույն մեքենայի վրա։
Ուշադրություն դարձրեք, թե հասցեների որ ընտանիքներին են լուծվում աղբյուրները։ Կանոնը, որը թույլ է տալիս միայն IPv4, շարունակելու է ձախողվել այն հոսթի վրա, որի աղբյուրները նախընտրում են AAAA գրառումը, և սխալը թվում է ընդհատվող, որովհետև կախված է նրանից, թե որ պատասխանն է առաջին հասնում։
Ընտրեք սպասարկման մեկ ուղի և պահեք այն
Գոյություն ունեն երեք պաշտպանելի տարբերակներ՝ սպասարկման տրաֆիկը թունելով, կառավարվող թարմացման վստահված սերվերի միջոցով կամ նեղ ուղղակի բացառությամբ։ Ընտրեք մեկը գիտակցաբար և հասցրեք, որ resolver-ը համաձայնի, որովհետև այն բաժանումը, երբ անունները լուծվում են մի ուղղությամբ, իսկ միացումները գնում են մյուսով, ստեղծում է խափանումներ, որոնք ոչ ոք չի կարող բացատրել։
Ինչ էլ ընտրեք, այն չպետք է դառնա անսահմանափակ պահուստային ուղի։ Եթե ուղղակի ելքային տրաֆիկն արգելված է, երբ թունելը կանգնած է, ապա սպասարկման բացառությունը, որը լուռ թույլ է տալիս ամեն ինչ, ուղղման քողի տակ թաքնված քաղաքականության փոփոխություն է։ Թունելի սեփական վերջնակետը և bootstrap-ի կարիքները պահեք պահոցի հասանելիությունից առանձին կատեգորիայում, որովհետև դրանք մատնանշում են տարբեր նպատակակետեր և ձախողվում են տարբեր ձևերով, ուստի մեկ բացառությունը չի կարող ծածկել մյուսին։
Ստուգեք առանց ստուգումները թուլացնելու
Կիրառեք շրջանակը այն firewall-ի միջոցով, որն արդեն տիրապետում է քաղաքականությանը, փոխարենը երկրորդ կառավարիչ ավելացնելու, որովհետև մի ուղեցույց օգտագործել է այն։ Այնուհետև գործարկեք մետատվյալների թարմացում և մեկ իրական փաթեթային գործարք պահպանվող քաղաքականության ներքո, և կարդացեք ելքը, այլ ոչ միայն ելքի կարգավիճակը։
Հաջող տրանսպորտը ստուգումը թուլացնելու թույլտվություն չէ։ Արխիվի վավերացումը և TLS սերվերի ինքնությունը առանձին երաշխիքներ են, և դրանցից որևէ մեկի անջատումը սխալը լռեցնելու համար փոխում է այն, ինչին վստահում եք, ոչ թե այն, ինչին կարող եք հասնել։
Ավարտեք առանց թունելի դեպքի գիտակցված փորձարկմամբ։ Իմանալը, թե ինչպես է դարպասն իրեն պահում առանց իր թունելի, նախագծի մասն է, իսկ դա ընդհատման ժամանակ հայտնաբերելը՝ ոչ։ Իջեցրեք թունելը, գործարկեք մետատվյալների թարմացումը և հաստատեք, որ հոսթը ձախողվում է ձեր նախատեսած ձևով, այլ ոչ թե լուռ վերադառնում է բաց ուղի։ Պահոցի և վստահված սերվերի հավատարմագրերը պահեք ընդհանուր ախտորոշումից դուրս և թողեք գրառում, որը նշում է, թե ում է պատկանում թարմացման ուղին։