Առանց պատասխանի ելքային ESP-ը չի նշանակում, որ VPN-ը մեռած է
ESP-ն պաշտպանում է մեկ ուղղություն յուրաքանչյուր ասոցիացիայի համար և ոչինչ չի հաստատում։ Համաձայնեցրեք ներքին զրույցը և մուտքային SA-ն, նախքան սերվերը չպատասխանող անվանելը։
Դուք գրավել եք տրաֆիկը IPsec հոսթի վրա, տեսել եք ESP փաթեթների մեկնումը, ոչինչ չեք տեսել վերադառնալիս և եզրակացրել, որ հեռավոր կողմը փչացած է։ Գրառումը չի հաստատում այդ եզրակացությունը։ ESP-ն պաշտպանում է զրույցի մեկ ուղղություն և ոչինչ չի հաստատում IP մակարդակում, ուստի վերադարձող ESP-ի բացակայությունը կարող է նույնքան հեշտությամբ նշանակել, որ հավելվածը խոսելու բան չուներ, որքան այն, որ թունելը մեռած է։ Կարդացեք ներքին փոխանակումը և ընդունող կողմի վիճակը, նախքան կողմերից որևէ մեկին մեղադրելը։
Առասպելը. յուրաքանչյուր պաշտպանված փաթեթ արժանի է պատասխանի
ESP-ն հարցում-պատասխան արձանագրություն չէ։ Այն գաղտնագրում և նույնականացնում է այն ամենը, ինչ ընտրում է քաղաքականությունը, իսկ ընդունողը ստուգում, վերծանում և հանձնում է այդ ներքին փաթեթը՝ առանց սեփական փաթեթ ստեղծելու։ UDP հարցումը, որն անտեսում է նշանակակետը, կամ ICMP արձագանքը, որը մերժում է մուտքային քաղաքականությունը, ստեղծում են լռություն երկու ուղղություններում՝ որպես ճիշտ արդյունք։ Այդ լռությունը տրանսպորտի խափանում համարելը ձեզ ուղարկում է փնտրելու ցանցային խափանում, որը երբեք չի եղել։
Այն, ինչ իրականում ապացուցում է միակողմանի գրառումը, այն է, որ ուղարկողի կույտը ինչ-որ բան գաղտնագրել է այդ դիտարկման կետում։ Ոչինչ ժամանման մասին և ոչինչ պատասխանելու մտադրության մասին։ Օգտակար հարցը ոչ թե "ինչու պատասխան չկա" է, այլ "ինչ պետք է արտադրեր ներքին զրույցը"։
Երկու SA, երկու SPI, մեկ զրույց
IPsec անվտանգության ասոցիացիաները միակողմանի են, ուստի սովորական պաշտպանված փոխանակումն ունի մուտքային և ելքային ասոցիացիա՝ առանձին նույնացուցիչներով և անկախ վիճակով։ Ելքային փաթեթի SPI-ով վերադարձող տրաֆիկ փնտրելը հետևաբար կատեգորիայի սխալ է, քանի որ ցանկացած պատասխան անցնում է գործընկերոջ սեփական ելքային SA-ի տակ՝ իր իսկ SPI-ով։ Փոխարենը համադրեք զույգը տրաֆիկի ընտրիչներով և գործընկերոջ հասցեներով։
Բանալիների նորացումը բարդացնում է պատկերը մի քանի վայրկյանով, քանի որ հին և փոխարինող վիճակը կարող են համընկնել։ Եթե ախտանիշը սկսվել է բանալիների նորացման շուրջ, հավաքեք ասոցիացիաների նույնացուցիչները և ժամանակային նշանները միասին, ոչ միայն կապի անունը։
Ինչ պետք է անի ընդունողը, նախքան ինչ-որ բան պատասխանելը
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Յուրաքանչյուր տող ձախողվում է ինքնուրույն, և յուրաքանչյուր ձախողում ունի տարբեր տեր, այդ պատճառով մեկ գրառում չի կարող տարբերել դրանք։ Մուտքային հաշվիչը ժամանման միակ ուղղակի ապացույցն է, քանի որ փաթեթը, որը ձախողում է նույնականացումը կամ կրկնության ստուգումը, հեռացվում է առանց որևէ պատասխանի։ Այն գործընկերը, որի մուտքային հաշվիչը չի շարժվել, հետևաբար ձեզ ոչինչ չի հաղորդում իր քաղաքականության մասին։
Առաքումը վերծանումից առանձին քայլ է։ Վիճակը կարող է վավեր լինել, և փաթեթը հետագայում դեն նետվի մուտքային քաղաքականության կամ երթուղու կողմից, որը չի ներառում ներքին նշանակակետը, ուստի ստուգեք՝ արդյոք թիրախ հոսթը տեսել է բաց տեքստ, փոխարենը ենթադրելու, որ մաքուր հաշվիչը նշանակում է, թե փաթեթը գնացել է այնտեղ, ուր ցանկանում էիք։
Բնիկ ESP-ը UDP չէ
Բնիկ ESP-ը IP 50 արձանագրությունն է, որը ոչ TCP է, ոչ UDP և ընդհանրապես պորտ չունի։ Ուստի UDP 500-ի վրա IKE թույլատրող ֆայրվոլի կանոնը ոչինչ չի ասում տվյալների ուղու մասին, և պորտերի շուրջ գրված զտիչը կարող է թույլ տալ թունելին բանակցել, ապա դեն նետել այն ամենը, ինչ տեղափոխվում է նրա ներսում։ Փորձարկեք տվյալների ուղին առանձին՝ այն ռեժիմում, որն իրականում դիտել եք։
NAT-ի հետևում ձևը փոխվում է. պաշտպանված բեռը շարժվում է UDP-ի ներսում, սովորաբար 4500 պորտում, ինչպես սահմանում է RFC 3948-ը։ Գրանցեք ակտիվ ռեժիմը նախքան որևէ կանոն գրելը, քանի որ ուղու վրա գտնվող սարքը կարող է բնիկ ESP-ին և UDP-ում փաթեթավորված ESP-ին բոլորովին այլ կերպ վերաբերվել, և որոշ միջանկյալ արկղեր թույլատրում են մեկին և դեն նետում մյուսը։
Կարդացեք հաշվիչներ, որոնք պատկանում են այս դեպքին
strongSwan հոսթի վրա swanctl --list-sas-ը հաշվետվում է փաթեթների և բայթերի հաշվիչներ յուրաքանչյուր ասոցիացիայի համար երկու ուղղությամբ, ինչը բավական է տարբերելու "երբեք չի ժամանել" և "ժամանել է, բայց չի պատասխանվել" դեպքերը։ Linux-ում /proc/net/xfrm_stat-ը հաշվում է համախմբված ձախողումներ, ինչպիսիք են բացակայող վիճակը, բացակայող քաղաքականությունը և արձանագրության սխալները։ Այդ գումարները կուտակվում են գործարկումից և պատկանում են մեկ ցանցային անվանատարածքի, ուստի մեծ թիվը դեռ վերագրում չէ։
Վերցրեք երկու ընթերցում դեպքի պատուհանի շուրջ ճիշտ անվանատարածքում և համեմատեք տարբերությունները, հակառակ դեպքում անցյալ շաբաթվա սխալները կկպցնեք այսօր կեսօրի տոմսին։ Գրեք անվանատարածքը և երկու ժամանակային նշանները տոմսի մեջ, որպեսզի հաջորդ ընթերցողը կարողանա վերարտադրել համեմատությունը՝ գումարին վստահելու փոխարեն։
Անվանեք փուլը, ոչ թե կասկածյալին
Օգտակար եզրակացությունը նշում է, թե որտեղ կանգնեց փաթեթը. երբեք չի ստացվել, ստացվել և դեն նետվել, հանձնվել է, բայց պատասխան չի ստացել, կամ պատասխանվել է և կորսվել վերադարձի ճանապարհին։ Այս ամենը մատնանշում է տարբեր տեր և տարբեր հաջորդ հրաման։ "VPN սերվերից պատասխան չկա" արտահայտությունը չորս տարբեր խափանումներ է սեղմում մեկ նախադասության մեջ, որին գրառումը երբեք չի արդարացրել։
Գրառումները պահեք նեղ, իսկ հում միջուկային վիճակը՝ տոմսերից դուրս, քանի որ այն կարող է կրել բանալու նյութ, որին հոսթից դուրս անելիք չկա։ Հաշվիչների տարբերությունները և ժամանակային նշանները այն մասերն են, որ արժե փոխանցել հաջորդ մարդուն։