IKEv2 հաճախորդին հասնելը նրա հատկացված վիրտուալ IP-ով

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

Թունելը չի ուղղում աղբյուրի հասցեն

CHILD SA-ն ընդգրկում է երթևեկության ընտրիչների զույգ՝ մեկը յուրաքանչյուր կողմի համար, և թույլատրում է երթևեկություն այդ զույգի երկու ուղղություններով։ Այն ոչինչ չի ասում այն մասին, թե որ գործընկերն է առաջինը բացել IKE փոխանակումը։ Դարպասը, որը սկզբում լսում էր թունելին, դեռ կարող է ուղարկել առաջին հավելվածի փաթեթը, պայմանով, որ ընտրված աղբյուրն ու նպատակակետը ընկնեն տեղադրված ընտրիչների մեջ։ Երբ հարցումը դուրս է գալիս սխալ ինտերֆեյսից, այն պարզապես պիտանի չէ թունելի համար։

Դեպի հաճախորդ երթուղավորումը անհրաժեշտ է և բավարար չէ։ Քաղաքականությունը պետք է ընդունի այն աղբյուրը, որը դուք իրականում օգտագործել եք։

Կարդացեք տեղադրված քաղաքականությունը, ոչ թե կոնֆիգուրացիայի ֆայլը

Սկսեք ակտիվ ասոցիացիայից և դրա ընտրիչներից, որովհետև դինամիկ հատկացումը փոխում է այն, ինչ տեղադրված է միջուկում։

ipsec statusall
ip xfrm policy

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

Հաճախորդը պետք է լսի այնտեղ, որտեղ հասնում է փաթեթը

Նույնիսկ կատարյալ քաղաքականությունը հասնում է փակ պորտի, երբ ծառայությունը կապվում է միայն loopback-ին։ Լսողը պետք է լինի հատկացված հասցեի կամ տեղական ձևանմուշային հասցեի վրա։

ss -ltnp 'sport = :9090'
iptables -S INPUT

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

Փորձարկեք նոր ուղղությունն առանձին

Աշխատող հարցումը հաճախորդից սերվեր երբեք չի անցնում այս ուղով։ Ստեղծեք հարցումը դարպասից և դիտարկեք երկու ծայրերը։

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

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

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