WireGuard պրոֆիլ IPsec դարպասի համար. ինչ պահանջել փոխարենը

Լուռ դարպասի հետ ձեռքսեղմման ժամկետանցումները սովորաբար նշանակում են երկու արձանագրություն, որոնք երբեք չեն հանդիպում։ WireGuard գործընկերը խոսում է Noise, մինչդեռ IPsec դարպասը սպասում է IKE։ Ճիշտ հասցեն ու պորտը դա չեն փոխում։

Պրոֆիլում վերջնակետի վերօգտագործումը չի կամրջում երկուսին։ Հաջորդ քայլը դարպասը կառավարողին ուղղված հարցումն է։

Առաջին հարցումը. արձանագրության տարբերակը

IPsec-ը անվանում է ընտանիք, ոչ թե մեկ աշխատահոսք։ IKEv2-ը և IKEv1-ը տարբերվում են իրենց փոխանակումներով, նույնականացման տարբերակներով և ցանցի փոփոխության ընթացքում վարքով։ Միայն IKEv1-ը ավարտող դարպասը բոլորովին այլ կերպ կվարվի, քան IKEv2 առաջարկողը։ Հաճախորդի կարգավորումը փոխվում է դրա հետ։

Հարցրեք, թե որ տարբերակն է ավարտում ծառայությունը և արդյոք այն աշխատեցնում է ստանդարտների վրա հիմնված իրականացում, թե սեփական հաճախորդով մատակարարի տարբերակ։ Օպերացիոն համակարգերի ընտրացանկերը հաճախ թաքցնում են այդ պատասխանը մեկ պիտակի հետևում։ Պիտակը արձանագրությունը չէ։

Երկրորդ հարցումը. հաճախորդի նույնականացման մեթոդը

Նույնականացումը այն տեղն է, որտեղ գտնվում է իրական աշխատանքի մեծ մասը։ Ծառայությունը կարող է ակնկալել որոշակի ընդլայնված բանալու օգտագործմամբ մեքենայի վկայական, օգտվողի վկայական, EAP մեթոդ IKEv2-ի վրա կամ ինքնությանը կապված նախապես համօգտագործված բանալի։ Որն է գործում, դա որոշում է, թե ինչ է պետք հաճախորդին։

WireGuard-ի մասնավոր բանալին այդ ամենից ոչինչ չէ։ Դա Curve25519 բանալի է, որն օգտագործվում է մեկ կոնկրետ ձեռքսեղմման մեջ։ Ոչ մի փոխարկում այն վկայական կամ EAP հավատարմագիր չի դարձնում։ Գործիքը, որ հակառակն է պնդում, վերանվանում է ֆայլը կամ ստեղծում է անկապ մի բան։

RFC 7296-ում IKEv2 ճշգրտումը նկարագրում է, թե ինչ պետք է աջակցի այդ տարբերակի իրականացումը։ Դա օպերատորի անորոշ պատասխանի համար տեղեկագիր է, ոչ թե հաճախորդի կարգավորման ուղեցույց։

Երրորդ հարցումը. վստահելի ինքնությունը և նպատակակետերը

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

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

Վերջնակետի ստուգումը պատասխանում է հաճախորդի սխալից տարբեր հարցի։ Հասանելի պորտն առանց միացման մատնանշում է նույնականացում, իսկ անհասանելի պորտը՝ ուղին։

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

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

Երբ երկու արձանագրությունները պետք է գոյակցեն

Երկու ցանցերի կառավարումը երկու արձանագրությունները պահելու օրինական պատճառ է։ Սովորական ձևավորումը WireGuard-ը և IPsec-ը ավարտում է առանձին ինտերֆեյսներում կամ առանձին դարպասներում։ Հաստատված երթևեկությունն այնուհետև երթուղվում է նրանց միջև։

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

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

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