IKEv2-ը օգտագործում է UDP 500 և 4500. ո՞րն է տանում տվյալները։

UDP 500-ը firewall-ում բացելը թույլ է տալիս թունելին բանակցել, և հետո կապը դադարում է երթևեկություն անցկացնել։ Պորտերի ցանկը թերի էր, ոչ թե սխալ։ IKEv2-ը սկսվում է մեկ սոքեթի վրա և շատ իրական տեղաբաշխումներում շարունակվում է մյուսի վրա, մինչդեռ բեռը կարող է ընդհանրապես պորտ չլինել։ Փուլերը հերթականությամբ կարդալը բացատրում է, թե որ կանոնն է բացակայում։

Երկու պորտ, երկու աշխատանք

IKEv2-ը սկսվում է բանալիների փոխանակմամբ UDP 500-ի վրա, որտեղ կողմերը նույնականացվում են և թունելի համար հաստատում անվտանգության ասոցիացիա։ Հաջորդող տվյալների ուղին առանձին հարց է. այն կարող է լինել բուն ESP, որը IP պրոտոկոլի համար է, ոչ թե պորտ, կամ UDP-ում փաթեթավորված երթևեկություն 4500-ի վրա։ Դրանք firewall-ի վերանայման մեջ իրարից անջատ պահելը տարբերությունն է բանակցող թունելի և աշխատող թունելի միջև։ Մեկ սոքեթը տանում է կառավարումը, մյուսը՝ բեռը։

Այդ պատճառով միայն 500-ը թույլատրող կանոնը ստեղծում է ամենաշփոթեցնող ախտանիշը ողջ պրոտոկոլների ընտանիքում. բանակցությունը հաջողվում է, և ոչ մի օգտակար բան չի հետևում։ Վիճակը ցույց է տալիս զուգընկեր, մատյանը ցույց է տալիս հաստատված IKE SA, և հավելվածը դեռ ժամկետանց է լինում։ Բացակայող թույլտվությունը պատկանում է այլ հոսքի, քան այն, որ հենց նոր հաջողվեց։

Ինչու է 4500-ը ընդհանրապես գոյություն ունի

Շատ NAT սարքեր չեն կարող փոխանցել TCP-ից կամ UDP-ից տարբեր պրոտոկոլ, և ոմանք հասցեները վերագրում են այնպես, որ կոտրում են ESP-ի ամբողջականության ստուգումը։ ESP-ը UDP-ի մեջ փաթեթավորելը լուծում է երկու խնդիրն էլ՝ լրացուցիչ վերնագրի և թույլատրելի երկրորդ պորտի գնով։ Հենց այդ փաթեթավորումն է երկրորդ պորտի գոյության պատճառը։

NAT-ը հայտնաբերելուց հետո IKE-ն ինքն էլ տեղափոխվում է 4500, որպեսզի ամբողջ երթևեկությունը կիսի մեկ ուղի թարգմանչի միջով։ Չորս բայթանոց նշիչը, որը ESP չէ, այդ սոքեթում կառավարման հաղորդագրությունները տարբերում է տվյալներից։ Փոխանցումը պրոտոկոլի որոշում է, ոչ թե ադմինիստրատորի նախընտրություն։

Որտեղ է փոխվում աղբյուրի պորտը

Թարգմանիչը կարող է վերագրել հաճախորդի աղբյուրի պորտը, ուստի սերվերում երևացող tuple-ը չի համընկնում հաճախորդի tuple-ի հետ։ Նայեք յուրաքանչյուր NAT ցատկի երկու կողմերին, նախքան եզրակացնելը, որ կանոնն անտեսվում է։ Միայն հաճախորդի վրա ախտորոշումը կարող է տալ կանոն, որը ճիշտ է թվում և այնուամենայնիվ ձախողվում է։

MOBIKE-ունակ իրականացումները կարող են նաև անցնել 4500-ի առանց NAT-ի հայտնաբերման, և որոշ տեղաբաշխումներ դիտավորյալ պարտադրում են այդ ուղին։ Ուստի 4500-ը տեսնելը որոշման ապացույց է, ոչ թե տնային երթուղիչի ապացույց։

Ստուգեք երկու հոսքերն էլ ամեն սահմանում

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

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

Firewall-ի ցանկում ESP տողը պրոտոկոլի համընկնում է, ուստի պորտի կանոնը երբեք չի ծածկում այն։ Եթե օպերատորն օգտագործում է հատուկ պորտ, հետևեք փաստաթղթավորված կարգավորմանը երկու ծայրերում, քանի որ հաճախորդը չի կարող սերվերում լսող ստեղծել՝ ընտրելով ծանոթ համար։

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