Կայք-կայք VPN-ի պատասխանը թունելով չի անցնում
Թունելը շրջանցող պատասխանը հեռավոր կողմի երթուղային որոշումն է։ Ստուգեք հոսթերի աղյուսակը, սելեկտորները և rp_filter-ը, ապա ընտրեք երթուղի կամ NAT։
Առավոտն անցկացրի մի թունելի վրա, որը մաքուր բարձրացավ և երթևեկությունը տեղափոխում էր ուղիղ մեկ ուղղությամբ՝ մասնաճյուղը հասնում էր գլխամասային գրասենյակի ֆայլային սերվերին, և գլխամասից մասնաճյուղ բացված յուրաքանչյուր կապ մահանում էր առաջին SYN-ի վրա։ SA-երը բարձրացած էին, թունելի հաշվիչները աճում էին, և ձեռքսեղմումը երբեք խնդիրը չէր։ Պատասխանն ուղղորդվում էր մի տեղ, որը թունելը չի ծածկում, և այդ ընտրությունը հեռավոր կողմինն է։ Կայք-կայք VPN-ը տեղափոխում է միայն այն փաթեթները, որոնք հոսթը հանձնում է դարպասին, և յուրաքանչյուր հոսթ այդ ընտրությունը կատարում է առանձին՝ յուրաքանչյուր ուղղությամբ, իր իսկ երթուղային աղյուսակից։
Երկու ուղղություններն առանձին են երթուղվում
IP-ն որևէ հիշողություն չի պահում զրույցի ուղղության մասին։ Փաթեթ ուղարկող յուրաքանչյուր հոսթ կատարում է ամենաերկար նախածանցի իր որոնումը, ընտրում է մեկ հաջորդ ցատկ և մոռանում որոշումը։ Հարցումն ու պատասխանը երկու անկապ փաթեթներ են, որոնք պատահաբար նույն կապին են պատկանում, իսկ թունելը մեկ ցատկ է, որից դրանցից ցանկացածը կարող է օգտվել կամ չօգտվել։ IKE փոխանակման մեջ ոչինչ չի սովորեցնում հեռավոր սերվերին, թե ինչպես հասնի ձեր ենթացանցին. բանակցությունը միայն համաձայնում է, թե որ նախածանցերը կարելի է գաղտնագրել։
Այդ համաձայնությունը երկրորդ դարպասն է։ strongSwan-ում երթևեկության սելեկտորներն են leftsubnet և rightsubnet, և այն փաթեթը, որի աղբյուրը կամ նպատակակետը դուրս է բանակցված զույգից, չի գաղտնագրվում, ինչ էլ ասի երթուղային աղյուսակը։ Նախածանցը, որը երթուղվում է թունելի մեջ, բայց բացակայում է սելեկտորներից, հանգիստ միակողմանի ձախողում է. երթուղին ճիշտ է թվում, փաթեթը դեռ դուրս է գալիս բաց կամ դեն է նետվում, և միայն charon-ի մատյանն է բողոքում։
Հեռավոր հոսթը ոչինչ չգիտի ձեր թունելի մասին
Հեռավոր տեղական ցանցի ներսում պատասխանը սովորական փաթեթ է՝ ուղղված ձեր սպասարկողին։ Նպատակակետ հոսթը ոչ մի IPsec վերնագիր չի տեսնում և պատճառ չունի նախընտրելու VPN դարպասը. այն որոնում է ձեր նախածանցը, ավելի կոնկրետ ոչինչ չի գտնում, քան իր լռելյայն երթուղին, և հետևում է դրան։ Եթե լռելյայնը մատնանշում է հիմնական ֆայրվոլին, ապա ֆայրվոլն ունի թունել վերադառնալու երթուղի, թե ոչ։ Երբ չունի, դուք ստանում եք հանգիստ բացթողում, ICMP unreachable կամ պատասխան, որը դուրս է գալիս ինտերնետին նայող ինտերֆեյսով և մահանում։
Երկրորդ ինտերֆեյսը բավական է դա կոտրելու համար, նույնիսկ երբ երթուղի գոյություն ունի։ Մեկ այլ VLAN-ում կառավարման կապ ունեցող NAS, պահուստային uplink-ով սերվեր, քաղաքականության կանոն, որը մեկ աղբյուրի տիրույթ ուղարկում է երկրորդ աղյուսակ. այս ցանկացածը կարող է որսալ պատասխանը։ Linux-ում ip rule show և ip route show table all ցույց են տալիս կանոններ և աղյուսակներ, որոնք լռելյայն ցանկը թաքցնում է։
Կարդացեք որոշումը պատասխանն ուղարկող մեքենայի վրա
Հարցրեք միջուկին նախքան որևէ բան փոխելը, և տվեք նրան աղբյուրի հասցեն, որովհետև աղբյուրից կախված կանոնները փոխում են պատասխանը։
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"Արդյունքը նշում է ելքային ինտերֆեյսը և հաջորդ ցատկը։ Եթե ինտերֆեյսը այն չէ, որ նայում է VPN դարպասին, դուք գտել եք թերությունը, և մնացած աշխատանքը երթուղու տեղն ընտրելն է։ Դարպասից արված ping-ն այստեղ քիչ բան է ապացուցում. այն պատասխանում է հասցեով, որը հեռավոր հոսթը կարող է տեղադրել, ոչ ձեր նոթբուքի հասցեով։
Windows-ում համարժեքներն են Find-NetRoute -RemoteIPAddress 10.10.5.10-ը որոշման համար և Get-NetRoute-ը աղյուսակի համար։ New-NetRoute-ով ավելացված երթուղին, որն ավելի բարձր մետրիկա ունի, քան լռելյայնը, հանգիստ պարտվում է, ուստի կարդացեք մետրիկայի սյունը, ոչ թե գրառումը։ Ապա հաստատեք փաթեթներով. tcpdump -ni any "host 10.10.5.10 and tcp port 445"-ը հեռավոր LAN ինտերֆեյսի վրա ցույց է տալիս հարցումը, և նույն զտիչը թունելի կողմում ցույց է տալիս՝ պատասխանը վերադարձե՞լ է։ Տեսանելի հարցում առանց պատասխանի նշանակում է, որ պատասխանն այլ տեղ է երթուղվել կամ դեն է նետվել. սխալ ինտերֆեյսի վրա պատասխանը ձեզ տալիս է մեղավորին նախքան երթուղուն դիպչելը։
Երբ սերվերի դարպասը VPN-ի վերջնակետը չէ
Շատ տեղամասեր ֆայրվոլ են դնում սերվերների և կենտրոնացուցիչի միջև։ Այդ ֆայրվոլը փոխանցում է պատասխանը, ուստի նրան պետք է երթուղի ձեր սպասարկողի նախածանցի համար՝ ուղղված դեպի VPN դարպասը, և փոխանցման քաղաքականություն երկու ուղղություններով։ Վիճակ պահող սարքերը վատթարացնում են. հարցումը հատել է ֆայրվոլը այն LAN հոսթից, որը նա թույլատրել է, պատասխանը հիմա գալիս է մեկ այլ ուղղությունից, և կապի հետևման գրառումն այլևս չի համընկնում, ուստի փաթեթը դեն է նետվում որպես անվավեր, այլ ոչ թե մերժված։ Այդ պատճառով քաղաքականության մատյանը դատարկ է երևում, մինչ երթևեկությունը անհետանում է։
Դարպասն ունի իր երկրորդ զտիչը։ Linux-ի հակադարձ ուղու զտումը դեն է նետում այն փաթեթները, որոնց աղբյուրը հասանելի չէ այն ինտերֆեյսով, որով նրանք եկել են, և դա հենց օրինական ասիմետրիկ վերադարձի ուղու ձևն է։ strongSwan-ի փոխանցման ուղեցույցը հենց այդ պատճառով պահանջում է net.ipv4.ip_forward և թուլացված net.ipv4.conf.all.rp_filter։ 1-ի խիստ արժեքը ցանկացած դարպասի վրա հանգիստ կոտրում է ճիշտ երթուղին, և nstat -az ցույց է տալիս բացթողումները, եթե գիտեք, թե ուր նայել։
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Երթուղավորեք կամ թարգմանեք, ապա ստուգեք երկու ուղղություններով
Երկու վերանորոգումները համարժեք չեն։ Երթուղի ավելացնելը սպասարկողի հասցեն անձեռնմխելի է պահում, ուստի աղբյուրի վրա հիմնված կանոնները, աուդիտի մատյանները և զանգահարողին գրանցող հավելվածները շարունակում են աշխատել. գինն այն է, որ որոշումը կայացնող յուրաքանչյուր ցատկ երթուղու կարիք ունի, այսինքն՝ սխալվելու ավելի շատ տեղեր։ Դիմակավորում հեռավոր դարպասի վրա վերադարձի ուղին սեղմում է մեկ ցատկի, որովհետև պատասխանն այժմ ուղղված է հենց դարպասին, և թաքցնում է, թե որ սպասարկողն ինչ արեց։
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEԸնտրեք այն գիտակցաբար. հենց սպասարկողները հայտնվեն որպես դարպասի հասցե, աղբյուրի վրա հիմնված ACL-ները դադարում են տարբերել նրանց, և conntrack-ը պետք է պահի քարտեզագրումը, որպեսզի պատասխանը հետ գրվի թունելի մեջ։ Եթե սելեկտորները դեռ բացառում են սպասարկողի նախածանցը, NAT-ը ոչինչ չի փոխում, որովհետև հարցումը երբեք չի մտել թունել։
Նախքան այն ուղղված հայտարարելը, հաստատեք չորս բան հերթականությամբ. երթուղին այն հոսթի վրա, որը պատասխանն ուղարկում է, երթուղին յուրաքանչյուր ցատկի վրա, որը փոխանցում է այն, սելեկտորները, որոնք ծածկում են երկու նախածանցները, և գրառում, որը ցույց է տալիս պատասխանի մուտքը թունել ձեր սպասած աղբյուրով։ Ապա կրկնեք փորձարկումը մյուս տեղամասից։ Մեկ ուղղության անցնելը կիսաբաց նախագիծ է, և երկրորդ ուղղությունը սովորաբար ձախողվում է այն պատճառով, որը տարբերվում է հենց նոր ուղղածից։