WireGuard-ի ձեռքսեղմումն աշխատում է, ծառայությունը՝ ոչ

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

Կանգ առեք առաջինի վրա, որը չի համապատասխանում, և մյուսների համար կանոններ չավելացնեք։

Ձեռքսեղմումը վկայում է միայն թունելը

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

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

Կարդացեք լսողը և երթուղին

Հաճախորդի վրա հաստատեք, որ սերվերի թունելի հասցեն երթուղվում է թունել։ Սերվերի վրա հաստատեք, որ սոքեթ գոյություն ունի հաճախորդի օգտագործած հասցեում, և որ դրա հետևում գտնվող գործընթացը նախատեսվածն է։

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

127.0.0.1-ի վրա լսողը երբեք չի պատասխանի 10.66.0.1-ին ուղղված հարցմանը, ինչ էլ թույլատրի հրապատը։ Ընդհանուր հասցեի վրա լսողը կպատասխանի, եթե կանոնը չարգելափակի այն։ Այսպիսով՝ սոքեթների ցանկը լուծում է դեպքերի կեսը մինչև որևէ կանոնի ստուգումը։ Պորտը և հասցեն միասին որոշում են՝ հարցումը կարող է հասնել, թե ոչ։

Համեմատեք հաճախորդի օգտագործած հասցեն այն հասցեի հետ, որն իրականում սերվերն ունի թունելի ինտերֆեյսում։ Հնացած կոնֆիգուրացիան ցանկացած կողմում ստեղծում է հարցում, որը ճիշտ է երթուղվում դեպի հավասար, որը նման հասցե չունի։

Կանոններ կիրառեք տեղական մուտքի, ոչ թե փոխանցման համար

Եթե փաթեթը հասել է, և սոքեթը գոյություն ունի, մնացած սահմանը մուտքային քաղաքականությունն է։ Փոխանցումը թույլատրող կանոնը չի թույլատրում տեղական առաքում, և մեկ ինտերֆեյսով սահմանափակված կանոնը կարող է չհամապատասխանել ձեր սպասած թունելի ինտերֆեյսի անվանը։

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

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

Առանձնացրեք անվան, չափի և ինքնության ձախողումները

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

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

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