Ինչպես կարդալ առաջին IKEv2 փոխանակումը փաթեթների գրավման մեջ

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

Համոզվեք, որ տեսնում եք բացման փոխանակումը

IKEv2 բանակցությունը սկսվում է IKE_SA_INIT-ով, փոխանակման 34 տիպով, հաղորդագրության 0 ID-ով։ Նախաձեռնողն ընտրում է ոչ զրոյական SPI, իսկ պատասխանողի SPI-ն այդ առաջին հարցման մեջ զրո է, իսկ պատասխանում՝ ոչ զրո։ Այդ երեք փաստերը տարանջատում են նոր փորձը բանալիների թարմացումից կամ գրավման գագաթին պատահաբար հայտնված IKE_AUTH հաղորդագրությունից։

Վերնագրի դաշտերը ընթեռնելի են, ինչպես նաև առաջարկի, բանալիների փոխանակման և nonce բեռնվածքները։ Ընթեռնելի լինելը վավերացված լինել չի նշանակում. այս պահին ոչ մի կողմ չի ապացուցել ինքնությունը, և Diffie-Hellman-ի գաղտնի արժեքը երբեք չի հայտնվում լարում։

Տպեք դաշտերը որպես աղյուսակ՝ վերծանման վահանակը ոլորելու փոխարեն, քանի որ կրկնակի ուղարկումներն ու չհամապատասխանող SPI-ները սյուներում ակնհայտ են դառնում։

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

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

Կարդացեք մերժումը նախքան հաջողությունը

Պատասխանը ինքնաբերաբար առաջընթաց չէ։ Պատասխանողը կարող է պատասխանել cookie ծանուցմամբ և սպասել, որ նախաձեռնողը նորից փորձի, կամ INVALID_KE_PAYLOAD-ով՝ նշելով մի խումբ, որը դրա փոխարեն կընդունի։ Երկուսն էլ գալիս են որպես ճիշտ ձևավորված IKE հաղորդագրություններ, և երկուսն էլ միայն փաթեթներ հաշվող զտիչին ավարտված փոխանակում են թվում։

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

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

4500 պորտը մեկ արձանագրություն չէ

Սովորաբար UDP 500-ն է կրում բացման փոխանակումը։ NAT-ի հայտնաբերումից հետո IKE-ն անցնում է 4500-ին և յուրաքանչյուր հաղորդագրության առջև դնում է չորս բայթանոց զրո, ոչ ESP նշիչ։ Նույն պորտում փաթաթված ESP-ը փոխարենը սկսվում է ոչ զրոյական ESP SPI-ով, և մեկ բայթանոց NAT keepalive-ը երրորդ ձևն է, որը հայտնվում է, երբ ուրիշ ոչինչ չի կատարվում։

Միայն պորտին համապատասխանող զտիչը խառնում է բոլոր երեքը, և դրա համար է, որ "4500-ում երթևեկություն կա" այդքան քիչ է որոշում։ Բաժանեք տեսքը ըստ արձանագրության՝ նախքան հեռավոր կողմի մասին որևէ եզրակացություն անելը։

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Լռությունը նկարագրում է դիտարկման կետը

Առանց պատասխանների հարցումները հաստատում են ուղիղ մեկ բան. այդ գրավման կետում ոչ մի պատասխան չհայտնվեց։ Զտումը, պատասխանն այլուր ուղարկող երթուղին, անհասանելի պատասխանողը կամ առաջարկը չսիրող պատասխանողը բոլորը տալիս են նույն դատարկ արդյունքը, և ընդհանուր UDP փորձարկումը չի տարբերի նրանց։

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

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

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