VPN հաճախորդը LAN սերվերի վրա՝ ինչու են պատասխանները դուրս գալիս սխալ ճանապարհով

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

Պատասխանը նոր փաթեթ է, ոչ թե ճանապարհի հակադարձում

Օգտակար է հրաժարվել այն գաղափարից, որ պատասխանը վերադառնում է այն նույն ճանապարհով, որով գնացել է հարցումը։ Երթուղավորումը որոշվում է յուրաքանչյուր փաթեթի և յուրաքանչյուր ուղղության համար՝ ուղարկող հոսթի վրա։ Թունելի ներսում 10.64.0.23-ից եկած հարցումը վերադարձի ճանապարհ չի ստեղծում՝ երբ հոսթը պատասխանում է, այդ պատասխանը որպես նոր փաթեթ համեմատվում է աղյուսակի հետ և դուրս գալիս այն երթուղով, որը հաղթում է։

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

Մնացածը կարդալիս երկու ենթացանց պահեք մտքում։ Մեկը VPN հասցեների լողավազանն է, որտեղից գալիս են հեռավոր հաճախորդները, այս օրինակում՝ 10.64.0.0/24։ Մյուսը LAN-ն է, որը պետք է շարունակի աշխատել՝ 172.16.24.0/24՝ իր երթուղիչով 172.16.24.1-ում։ Սխալն այն է, որ նրանց միջև երթևեկությունը որոշվում է լռելյայն երթուղով։

Ապացուցեք գրառմամբ և որոնմամբ

Նախքան ինչ-որ բան փոխելը՝ հաստատեք, թե որ սարքն է օգտագործելու պատասխանը։ Որոնումն ավելի արագ է, քան գրառումը, և պատասխանում է ճիշտ այն հարցին, որին կպատասխանի միջուկը փաթեթը կառուցելիս։

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Կարդացեք պատասխանը երկու մասով։ Եթե այն նշում է dev tun0, հոսթը կփաթաթի պատասխանը և կհանձնի մատակարարին, և LAN հաճախորդը երբեք չի տեսնի այն։ Եթե այն նշում է dev eth0, բայց հաճախորդը դեռ ժամկետանցում է ստանում, ապա երթուղին արդեն ճիշտ է, և փաթեթը հետո է դեն նետվում, ինչը այլ խնդիր է՝ այլ ուղղմամբ։

Նույն քայլի գրառումը լուծում է այն կասկածը, որը ping-ը չի կարող։ LAN հաճախորդին հասնող արձագանքը ապացուցում է, որ ինչ-որ ճանապարհ աշխատում է, ոչ թե այն, թե որ ինտերֆեյսն է տարել այն, ուստի գրառումը կատարեք հոսթի վրա և դիտեք, թե որտեղից են դուրս գալիս կադրերը։ Նույն ենթացանցի տպիչը շարունակում է պատասխանել, որովհետև նրա ուղիղ երթուղին ավելի կոնկրետ է, քան թունելի լռելյայն երթուղին։ Փոխանցված պորտը ձախողվում է ճիշտ ինչպես ցանկացած այլ հոսք, որովհետև ինտերֆեյսն ընտրում է աղյուսակը, ոչ թե կապը։

Տեղադրեք ամենանեղ երթուղին, որը գերազանցում է թունելին

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Օգտագործեք replace՝ add-ի փոխարեն, որովհետև նորից միացող հաճախորդն արդեն տեղադրել է իր գրառումը, և երկրորդ add-ը ձախողվում է գոյություն ունեցող երթուղու սխալով, որը կարդացվում է որպես թույլտվության խնդիր։ Windows հոսթի վրա համարժեքը route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p-ն է, որտեղ -p-ն պահում է գրառումը վերագործարկումների միջև, քանի որ հաճախորդը կարող է վերակառուցել աղյուսակը, երբ թունելը նորից բարձրանա։ Ժամանակակից Windows հոսթի վրա աջակցվող համարժեքը New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore-ն է, իսկ հին route հրամանը պահվում է որպես ժառանգված ձև։

Մի մանրամասն է որոշում՝ սա ճիշտ է, թե միայն հավանական՝ հաջորդ ցատկը պետք է լինի այն երթուղիչը, որն իսկապես տիրապետում է հաճախորդներին վերադարձի ճանապարհին։ Երթուղին մի հասցեի ուղղելը, որին ինքնին հասնում են թունելով, ստեղծում է օղակ, որը դրսևորվում է որպես ընդհատվող կորուստ, այլ ոչ թե մաքուր խափանում։ Հաստատեք, որ հաջորդ ցատկը LAN ենթացանցում է, նախքան տողը հաստատելը։

Պահեք պատասխանը կրկին միանալուց հետո

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

Վիճակային հրային պատնեշը դեռ կարող է հաղթել ճիշտ երթուղուն։ Եթե գրառումը հիմա ցույց է տալիս, որ պատասխանը դուրս է գալիս eth0-ով, և հաճախորդը դեռ ժամկետանցում է ստանում, ստուգեք՝ արդյոք հոսթը դեն է նետում փաթեթը ուղարկելուց առաջ։ Հակադարձ ուղու խիստ զտումը և net.ipv4.conf.all.rp_filter-ը 1-ի վրա դնելը դեն են նետում այն փաթեթները, որոնց աղբյուրը հետ չէր երթուղավորվի այն ինտերֆեյսով, որով եկել են, և դա հենց այն ասիմետրիկ դեպքն է, որը դուք հենց նոր ստեղծեցիք և հետո ուղղեցիք, իսկ conntrack-ի վիճակը նույն պատմությունն է պատմում փոխանցված պորտերի համար։

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