strongSwan ESP-in-UDP՝ երբ NAT չկա հայտնաբերելու

NAT-ի հայտնաբերումը պատասխանում է մեկ հարցի՝ փոխվել են արդյոք հասցեները կամ պորտերը ճանապարհին։ Այն չի պատասխանում, թե արդյոք firewall-ը թույլ է տալիս IP 50 արձանագրությունը։ Առանց որևէ թարգմանության կայքի դարպասները դեռ կարող են լինել այնպիսի քաղաքականության հետևում, որը գցում է native ESP-ն, և այդ պահանջը պետք է կարգավորվի, ոչ թե հայտնաբերվի։ Մեխանիզմը ESP-in-UDP-ն է, և սա որոշում է, ոչ թե ինքնըստինքյան հայտնվող պահուստային տարբերակ։

Հայտնաբերումը թվաբանություն է հասցեների վրա, ոչ firewall-ի ստուգում

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

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

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

Ինչպես է encap-ը փոխում փոխանակումը

Ժամանակակից strongSwan տեղակայման մեջ, որը կառավարվում է swanctl.conf-ի միջոցով, միացման վրա encap = yes կարգավորումը ազդում է NAT-ի հայտնաբերման փոխանակման վրա, որպեսզի երկու կողմերն էլ ESP-ի համար օգտագործեն UDP ինկապսուլյացիա։ Պաշտպանված փաթեթներն այնուհետև շարժվում են UDP-ի ներսում, սովորաբար 4500 պորտում, և երկու ծայրերը պետք է համաձայնեն այդ դասավորությանը։

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

strongSwan-ի NAT-traversal ուղեցույցը նկարագրում է այս վարքը, ներառյալ պորտի լողի հետ փոխազդեցությունը, երբ օգտագործվում է MOBIKE։

Օգտագործեք այն կարգավորումը, որը պատկանում է ձեր backend-ին

strongSwan-ն ունի երկու կարգավորման backend, և բանալին տարբերվում է նրանց միջև։ swanctl.conf միացումը վերցնում է encap, մինչդեռ հին ipsec.conf միացումը վերցնում է forceencaps։ Մեկ backend-ի հիմնաբառը մյուսի մեջ դնելը ստեղծում է կարգավորում, որը բեռնվում է առանց բողոքի և ոչինչ չի փոխում, ինչն ավելի վատ է, քան սխալը։

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

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

Ստուգեք փաթաթված տվյալները, ոչ միայն պորտը

Որսեք դարպասի վրա, մինչ պաշտպանված երթևեկությունը հոսում է, ապա համեմատեք դա strongSwan-ի սեփական տեսքի հետ.

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP-ն հայտնվում է որպես IP 50 արձանագրություն և բոլորովին նման չէ UDP-ի։ Փաթաթված ESP-ն հայտնվում է որպես UDP դատագրամներ 4500-ի վրա, որոնց բեռնվածքը IKE չէ։ Նույն պորտի IKE երթևեկությունը ինկապսուլյացիայի ապացույց չէ, որովհետև MOBIKE-ը կարող է IKE-ն տեղափոխել այնտեղ, մինչ տվյալների ուղին մնում է native, ուստի կարդացեք բեռնվածքը, ոչ թե պորտի համարը։

Հիշեք նաև ուղու MTU-ն։ Ծածկույթը ավելացնում է լրացուցիչ ծախս, և native ESP կրած ուղին կարող է ճշգրտումներ պահանջել, երբ փաթեթները մեծանան։ Պահանջվող ICMP մշակումը պետք է արդեն լինի նախագծի մաս. ինկապսուլյացիան չի վերացնում այդ կախվածությունը։

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