Երթուղավորված VPN հաճախորդը հասնում է սերվերին, բայց ոչ LAN հոսթերին

Թունելը բարձրանում է, հաճախորդը ping է անում VPN սերվերին, և մեկ քայլ հեռու մեքենայի ընդհանուր պանակը երբեք չի պատասխանում։ Հաճախորդի կարգավորումներում ոչինչ դա չի բացատրում, որովհետև հարցումն իսկապես լքել է հաճախորդին և իսկապես հասել։ Ձախողվել է վերադարձի ճանապարհը, և ձախողված սարքը սովորաբար LAN դարպասն է, ոչ թե VPN հոսթը։ Պատասխան փաթեթի հետագծումը բացատրում է ախտանիշների այս ամբողջ դասը։

Հետևե՛ք պատասխանին, ոչ թե հարցմանը

VPN սերվերը վերծանում է հաճախորդի փաթեթը և փոխանցում այն LAN, երբ հաճախորդի հասցեն դեռ աղբյուրի դաշտում է։ Նպատակակետ հոսթը պատասխանում է այդ հասցեին, և այժմ նրա սեփական երթուղային աղյուսակն է ամեն ինչ որոշում։ Նրա լռելյայն դարպասը ոչինչ չգիտի թունելի լողավազանի մասին, ուստի պատասխանը մեկնում է դեպի ինտերնետ մատակարար և ինչ-որ տեղ այդ ճանապարհին դեն է նետվում։

Հաճախորդի մոտ ախտանիշը լուռ ժամկետի սպառումն է՝ ոչ մերժում, ոչ վերականգնում, ուղղակի ոչինչ։ Ընդհանուր պանակի դիտումը կախվում է, ping-ը հայտնում է պատասխանի բացակայության մասին, և սերվերի մատյանները առողջ տեսք ունեն, որովհետև սերվերն արել է իր գործը։

Տեղադրե՛ք վերադարձի երթուղին այնտեղ, որտեղ նայում են հոսթերը

Յուրաքանչյուր LAN հոսթ խորհրդակցում է իր լռելյայն դարպասի հետ, ուստի դարպասն է միակ սարքը, որ պետք է իմանա, թե որտեղ է թունելի լողավազանը։ Այնտեղ ավելացրե՛ք ստատիկ երթուղի, և յուրաքանչյուր հոսթ ժառանգում է ճիշտ ուղին՝ առանց դիպչելու։

Եթե դարպասը բաժանում է իր սեփական հասցեն որպես DHCP ընտրանք, բաշխե՛ք երթուղին այդ կերպ, որպեսզի նոր մեքենաներն այն ինքնաբերաբար վերցնեն։ Հակառակ դեպքում երթուղին ապրում է մեկ կարգավորման ֆայլում և անհետանում հաջորդ վերակառուցման ժամանակ։

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Ինչու է թվում, թե աղբյուրային NAT-ը շտկում է դա

Հաճախորդների լողավազանը VPN սերվերի հասցեի հետևում քողարկելը վերացնում է խնդիրը՝ փաթեթից հեռացնելով հաճախորդի հասցեն։ Պատասխաններն այդ ժամանակ վերադառնում են սերվեր, որը դեռ գիտի, թե ինչպես հասնել թունելին, և ամեն ինչ աշխատում է։ Գինը այն է, որ ներքին հոսթերն այլևս չեն տեսնում, թե ով է հաճախորդը, և յուրաքանչյուր կապ կարծես մեկ մեքենայից է գալիս։

Այս փոխանակումը երբեմն ճիշտ է, օրինակ երբ մատակարարի սարքին հնարավոր չէ ստատիկ երթուղի տալ։ Կանոնը մի՛ դարձրեք ընթացիկ լողավազանից ավելի լայն, որովհետև /24-ի համար գրված կանոնը դադարում է համապատասխանել այն օրը, երբ լողավազանը վերահամարակալվում է /16-ի, և առաջին նշանը նոր հաճախորդների խումբն է, որոնք միանում են և ոչ մի տեղ չեն հասնում։

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Ամպային ուղին երեք կարգավորում է պահանջում

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

Յուրաքանչյուր բացթողում ստեղծում է առանձին մասնակի ձախողում։ Բաց թողե՛ք երթուղային աղյուսակի գրառումը, և մասնավոր օրինակները պատասխանում են ենթացանց, որը չի կարող պատասխանը հետ տանել լողավազան։ Ստուգումը միացված մնալու դեպքում հարթակը դեն է նետում պատասխանն այն բանից հետո, երբ օրինակն արդեն ուղարկել է այն։ Անվտանգության խմբի կանոնի բացակայության դեպքում հարցումն ինքը երբեք չի հասնում, և հաճախորդը ժամկետի սպառումը տեսնում է մեկ շերտ շուտ։

Կատարե՛ք ստուգումները այս հերթականությամբ

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

Ավարտե՛ք LAN հոսթի վրա վերցված որսով, մինչ հաճախորդը ping է անում նրան։ Համապատասխան պատասխան չունեցող հարցումը ապացուցում է վերադարձի ուղին, իսկ երբեք չհասնող հարցումը մեղքը հետ է մղում սերվերին կամ թունելին։

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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