Կայք-կայք VPN-ը աշխատում է միայն մեկ ուղղությամբ՝ երկու տարբեր խափանումներ

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

Այս տարբերությունն է որոշում, թե որ հրամաններն արժե գործարկել։

Երկու խափանում, որոնք նույնական են թվում

Առաջին դեպքում B-ի հոսթը SYN է ուղարկում A-ին, և ոչինչ չի վերադառնում։ Երկրորդում A-ի հոսթը հաջողությամբ բացում է նստաշրջան, և պատասխանը անհետանում է վերադարձի ճանապարհին։ Երկու օգտատերերն էլ ասում են, որ կապը միակողմանի է, և երկուսն էլ նկարագրում են անհետացած փաթեթ, ուստի նկարագրությունն ինքնին չի կարող նրանց բաժանել։

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

Այնուհետև ստուգեք, որ փորձարկումն ամբողջ ընթացքում օգտագործել է նույն հոսթերն ու նույն ծառայությունը։ Մի կողմից ping-ը և մյուս կողմից ֆայլերի ընդհանուր պանակի կապը ստուգում են երկու տարբեր բան, և դարպասից արված ախտորոշումը կարող է ընտրել թունելի այնպիսի հասցե, որը ոչ մի օգտատիրոջ երթևեկություն չի օգտագործում։

Առաջին դեպք՝ վերադարձի ուղին բացակայում է

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

Ստուգեք այն հասցեն, որը նպատակակետը իրականում տեսնում է թարգմանությունից հետո, և վերադարձի երթուղին այդ հասցեի համար, ոչ թե սկզբնական ենթացանցի։

Երկրորդ դեպք՝ քաղաքականությունը երբեք դա չի թույլատրել

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

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

Համեմատեք առաջ և հետո նույն հոսթերում

Դիտեք նույն փորձի երկու ծայրերը, ոչ թե երկու առանձին փորձ։ Գրառեք սկսող հոսթի դարպասի և նպատակակետի վրա, ապա համեմատեք, թե ինչ մտավ, ինչ դուրս եկավ և ինչ հասցե տեսավ հեռավոր կողմը։

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Եթե նպատակակետի գրառումը ցույց է տալիս հարցումը անսպասելի աղբյուրի հասցեով, պատասխանը թարգմանության կամ երթուղավորման մեջ է, ոչ թե թունելի անվտանգության քաղաքականության։ Եթե նպատակակետը ընդհանրապես հարցում չի ցույց տալիս, փաթեթը երբեք չի անցել պաշտպանված ուղին։

Ուղղումից հետո կրկնեք նույն փորձարկումը նույն հոսթից և հաստատեք, որ անկապ մուտքը դեռ մերժվում է։ “established” թունելի կարգավիճակը ինքնին չի հաստատում երկու եզրակացություններից ոչ մեկը։