Ստուգել, որ բաժանված թունելը աշխատում է. մեկ IP արդյունքը փորձարկում չէ

Մեկ բրաուզերի էջ, որը ցույց է տալիս IP հասցե, գրեթե ոչինչ չի ապացուցում բաժանված թունելի մասին։ Տեսանելի հասցեն կարող է ճիշտ լինել սխալ պատճառով, և բացառված հոսքը երբեք չի փորձարկվում դրանով։ Փորձարկումից առաջ գրեք սպասվող արդյունքը՝ որ հավելվածը կամ նպատակակետը պետք է օգտագործի թունելը, որը պետք է մնա ուղիղ, և ինչ պետք է կանգնի, երբ թունելը ձախողվի։ Առանց այդ պլանի ցանկացած հավանական թիվ հաջողություն է թվում։

Առասպել։ հասցեի որոնումը ապացուցում է ծածկույթը

IP ստուգումը պատասխանում է մեկ հարցի՝ ինչ է տեսնում արտաքին աշխարհը մեկ հավելվածից մեկ պահին։ Այն ոչինչ չի ասում ներքին նախածանցի, երկրորդ բրաուզերի պրոֆիլի կամ գաղտնի լուծվող անվան մասին։ Այն նաև ոչինչ չի ասում ձախողման մասին, և դա բաժանված թունելի ձևավորման այն կեսն է, որը կոտրվում է արտադրությունում։

Հասցեի էջը նույնպես չի կարող ցույց տալ երթուղին, լուծիչը կամ ձախողման քաղաքականությունը։ Դիտարկեք այն որպես մեկ դիտարկում, ոչ որպես դատավճիռ։

Փորձարկեք ներառված և բացառված հոսք

Ուղարկեք անվնաս հարցում այն հավելվածից, որը պետք է ներառվի, կամ այն նախածանցին, որը ակնկալում եք անցկացնել թունելով, և գրանցեք աղբյուրը, նպատակակետը, հասցեների ընտանիքը և դիտարկված ուղին։ Նույնը արեք այն հոսքի համար, որը պետք է մնա ուղիղ։ Բացառված կողմը այն է, որը մարդիկ բաց են թողնում, և դա միակ ապացույցն է, որ բաժանումը դիտավորյալ է, ոչ պատահական։ Օժանդակ գործընթացը կարող է կրել առանձին քաղաքականության ինքնություն, այնպես որ փորձարկեք այն գործընթացում, որը տիրապետում է վարդակին։

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Այդ պատճառով սխալ հավելվածում արված փորձարկումը կարող է ցույց տալ ձևավորման մտադրության հակառակը։ Ցանկացած եզրակացությունից առաջ գրեք չորս դաշտերը երկու կողմերի համար։

Ավելացրեք DNS-ը և ձախողման դեպքը

Հարցրեք համակարգի լուծիչին և այն լուծիչին, որն օգտագործում է հավելվածը, ապա համեմատեք այդ պատասխանները կայքի հաղորդած ելքի հասցեի հետ։ Երկու շերտերը կարող են դիտավորյալ տարբերվել, և մեկ բրաուզերի որոնումը չի փորձարկում օպերացիոն համակարգի քաղաքականությունը։ Կեղևը համեմատությունը դարձնում է կրկնելի՝ կոտրեք թունելը դիտավորյալ, ապա արեք հարցում, որը բրաուզերը չի պահել պահոցում՝ պահոցից մատուցված էջը ոչինչ չի ասում այն մասին, թե որ ուղղությամբ գնաց պահուստային ուղին։ Գրանցեք այն, ինչ իրականում պատահեց, ոչ այն, ինչ կանխատեսել էր ձևավորումը։

curl -s https://ifconfig.me
nslookup intranet.example

Փակ վիճակում ձախողվող բաժանված թունելը և բաց վիճակում ձախողվող թունելը նույնական են թվում, քանի դեռ դիտավորյալ չեք կոտրում թունելը։ Գրանցեք, թե որ վարքագիծը դիտարկեցիք, ոչ թե որը սպասում էիք։

Կրկնեք վիճակի փոփոխությունից հետո

Կրկնեք նույն դիտարկումները վերամիացումից, ցանցի փոփոխությունից և համապատասխան հավելվածի թարմացումից հետո։ Պահված բացառումը կարող է շարունակել մատնանշել ուղի կամ հավելվածի ինքնություն, որն այլևս գոյություն չունի, և ձևավորումը լուռ դադարում է համապատասխանել իր փաստաթղթերին։ Այդ երեք իրադարձություններն են, որտեղ բաժանված թունելները սահում են, և դրանցից յուրաքանչյուրը էժան է նորից փորձարկել։ Փորձարկումը, որը կատարվում է միայն մեկ անգամ տեղակայման ժամանակ, նկարագրում է կազմաձև, որն այլևս գոյություն չունի։

Եթե արդյունքը տարբերվում է, գտեք կանոնի տիրոջը և մշակման փուլը, նախքան միանգամից մի քանի կարգավորում փոխելը։ Հինգ բան փոխել և մեկ արդյունք դիտարկելը ախտորոշում չէ, դա նոր կազմաձև է։

Ինչ պետք է հաստատի արդյունքը

Կապեք դիտարկումները այն քաղաքականությանը և հաճախորդի տարբերակին, որը դուք իրականում ստուգել եք։ Նպատակն է ցույց տալ, որ այս տեղակայումը համապատասխանում է իր հայտարարած ծածկույթին, ոչ այն, որ յուրաքանչյուր ապագա հավելված կլինի գաղտնի։ Սա ավելի նեղ պնդում է, և հենց այն է, ինչը դուք իսկապես կարող եք հիմնավորել ապացույցներով։ Գրեք պնդումը, տարբերակը և չորս դաշտերի արդյունքները փոփոխությունների մատյանում։

Այնուհետև հաջորդ գրախոսը կարող է ասել՝ փոխվել է ձևավորումը, թե փորձարկումը։ Բաժանված թունելը հաստատված է, երբ երկու կողմերը, լուծիչի բաժանումը և ձախողման վարքագիծը համապատասխանում են այն ամենին, ինչ գրել եք սկզբում։ Մեկ IP արդյունքը ոչ մեկը դրանցից չի հաստատում։