ESP-ը IP 50 արձանագրություն է, ոչ թե TCP 50 պորտ. ինչ թույլատրել
Արձանագրության համարները և պորտի համարները տարբեր անվանատարածքներ են։ TCP 50 պորտի համար կանոնը ոչինչ չի թույլատրում, և NAT traversal-ը ESP-ն տեղափոխում է UDP 4500։
Firewall-ի ձևաթղթերը պահանջում են TCP պորտ, և ակնհայտ պատասխանը 50-ն է։ Այդ պատասխանը ոչինչ չի թույլատրում, որովհետև ESP-ը IP 50 համարով արձանագրություն է, իսկ արձանագրության համարները պորտեր չեն։ Երկու անվանատարածքները կիսում են միայն փոքր ամբողջ թվեր և ուրիշ ոչինչ, և սխալը անտեսանելի է մնում, մինչև IKE-ն ավարտվի, իսկ պաշտպանված երթևեկությունը երբեք չհասնի։
Երկու անվանատարածք, որոնք կիսում են փոքր թվեր
IP վերնագիրը կրում է արձանագրության դաշտ, որը նշում է, թե ինչ է հաջորդում՝ 6-ը TCP-ի համար, 17-ը՝ UDP-ի, 1-ը՝ ICMP-ի, 50-ը՝ ESP-ի, 51-ը՝ AH-ի։ TCP կամ UDP վերնագիրը կրում է պորտերի համարներ, որոնք ընտրում են գործընթաց նպատակակետ հոսթում։ 50 արձանագրությունը և TCP 50 պորտը անկապ արժեքներ են, բայց երկխոսության պատուհանը կարող է դրանք փոխարինելի թվացնել։
Այդ պատճառով պորտերի փոխանցման կանոնը չի կարող արտահայտել բնիկ ESP-ն։ Փոխանցելու համար ESP նպատակակետ պորտ չկա, և միայն պորտի կանոններ հասկացող սարքը բոլորովին բառապաշար չունի այդ փաթեթի համար։ Ճիշտ կանոնը փոխարենը նշում է IP արձանագրությունը։ Պորտերի ցանկացած երկխոսություն այդ փաթեթի համար սխալ գործիք է։
Շփոթմունքն ունի նաև երկրորդ կես։ Երբ փաթեթը գաղտնագրված է, ներսում ամեն ինչ անթափանց է, ներառյալ սկզբնական կապի TCP վերնագիրը։ Այդ փաթեթի պորտերը ստուգող firewall-ը նայում է արտաքին վերնագրին, որը բնիկ դեպքում ստուգելու պորտեր չունի։
Բնիկ ESP, ապա փաթեթավորված այլընտրանքը
Բնիկ ESP-ն ուղղակիորեն կրվում է որպես IP արձանագրություն, ինչը հավասարապես արդյունավետ և անհարմար է։ Արդյունավետ է, որովհետև լրացուցիչ վերնագիր չկա, և անհարմար է, որովհետև հասցեներ և պորտեր թարգմանող ցանկացած սարք չի կարող հետևել դրան։ NAT traversal-ը հենց դա լուծելու համար է՝ ESP փաթեթը փաթաթում է UDP-ի մեջ, որպեսզի թարգմանիչը վերաշարադրելու պորտեր ունենա։
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
Երկու ձևերը նույն տվյալների ալիքի այլընտրանքային տեղակայումներ են, ոչ թե մեկի շերտեր։ Բնիկ ESP-ն թույլատրելը չի թույլատրում փաթեթավորված ձևը, և UDP 4500-ը թույլատրելը չի թույլատրում բնիկ երթևեկությունը, ուստի կանոնների հավաքածուն պետք է համապատասխանի տեղակայմանը, այլ ոչ թե պատահաբար ծածկի երկուսը։
Հայտնաբերումն այստեղ նույնպես կարևոր է։ Ծայրակետերը բանակցության ընթացքում ընտրում են ձևերի միջև, և փոխարկումը սովորաբար տեղի է ունենում, երբ նրանց միջև NAT է հայտնաբերվում։ Այդ պատճառով թունելը կառուցելուց հետո փոխվող ուղին կարող է երթևեկությունը տեղափոխել անվանատարածք, որը ձեր կանոնները երբեք չեն ծածկել։
Կարդացեք, թե որ ձևն է իրականում օգտագործում կապը
Հարցրեք ծայրակետին՝ firewall-ից գուշակելու փոխարեն։ Linux-ում վիճակի գրառումը հայտնում է՝ արդյոք միավորումն օգտագործում է UDP փաթեթավորում և որ պորտերն են ներգրավված։ Փաթեթների գրավումը պատասխանում է նույն հարցին լարից, և երկուսն էլ ավելի արագ են, քան կանոնների հավաքածու կարդալն ու հուսալը։
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'Առաջին հրամանը ցույց է տալիս փաթեթավորման տեսակ, երբ NAT traversal-ը օգտագործվում է, և ոչինչ, երբ չի օգտագործվում։ Երկրորդը ցույց է տալիս, թե երկու ձևերից որն է իրականում անցնում ինտերֆեյսով, և դա ավարտում է վեճերը թղթի վրա ճիշտ թվացող կարգավորման մասին։
Հակափաստարկը նույն քայլի մասն է։ Զրո համընկնում հաղորդող կանոնը ձեզ ասում է, որ փաթեթը երբեք չի հասել դրան, և դա երթուղավորման կամ ընտրիչի հարց է, ոչ թե firewall-ի։
Ապա առանձին հաստատեք կառավարման ալիքը։ IKE-ն ունի իր պորտերը և իր մատյանները, և տվյալների առանց ավարտված բանակցությունը հենց այն բաժանումն է, որի մասին այս հոդվածն է։
Գրեք կանոնը ճիշտ անվանատարածքում
Արձանագրության կանոնը և պորտի կանոնը տարբեր հրահանգներ են, ուստի գործիքը պետք է արտահայտի այն, ինչ նկատի ունեք։ nftables-ում արձանագրության համընկնումը բացահայտ է, և փաթեթավորված այլընտրանքը ստանում է իր UDP կանոնը։ Պահեք երկու կանոնները կողք կողքի, որպեսզի զույգը տեսանելի լինի վերանայման ժամանակ։
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } acceptԴիմացեք գայթակղությանը լայնացնել կանոններից որևէ մեկը՝ սխալ ախտորոշումը փոխհատուցելու համար։ ESP արձանագրության համար ամեն ինչ թույլատրելը յուրաքանչյուր ինտերֆեյսում, կամ UDP-ի թույլատրումը ցանկացածից ցանկացածին, բուժում է ախտանիշը և հեռացնում այն վերահսկողությունը, որը փորձում էիք կարգավորել։ Նեղ աջակցվող հոսքը գրեթե միշտ բավարար է, երբ ձևը հայտնի է։
Վերջապես, շերտերը ուղիղ պահեք, երբ թունելն աշխատում է, իսկ հավելվածը՝ ոչ։ Դարպասին հասնող փաթեթները դեռ փոխանցում, վերադարձի ուղի և դրանք թույլատրող քաղաքականություն են պահանջում, և դրանցից ոչ մեկը ESP կանոնով արտահայտված չէ։ Բացակայող պորտը բացատրում է կոնկրետ ձախողում, ոչ թե IPsec-ի յուրաքանչյուր ձախողում։ Կանոնի ուղղումը և երթուղավորման ստուգումը պահեք որպես երկու առանձին եզրակացություն։
Գրանցեք ձեր դիտած ձևը, ավելացրած արձանագրության կանոնը և դրանից հետո տեսած հաշվիչը։ Երեք տող, և հաջորդ մարդը կարող է մեկ րոպեում տարբերել անվանատարածքի սխալը երթուղավորման սխալից՝ կես օրվա փոխարեն։