Հեռավոր օգտվողները չեն հասնում երկրորդ տեղամասին VPN հանգույցի միջով

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

Անցումը պահանջում է երեք որոնում, ոչ թե մեկ թունել

Յուրաքանչյուր սարք կատարում է իր ամենաերկար նախածանցի համընկնումը և մոռանում այն։ Դյուրակիր համակարգիչը պետք է 10.20.0.50-ը ուղարկի թունելի մեջ, այլ ոչ թե իր տեղական երթուղիչին։ Հանգույցը պետք է վերցնի հեռավոր մուտքի ինտերֆեյսով ժամանած փաթեթը և այն հանձնի տեղամաս-տեղամաս ինտերֆեյսին։ Գլխամասային գրասենյակը պետք է օգտվողի հասցեի պատասխանը հետ ուղարկի թունելով։ Երեքից ցանկացած մեկի ձախողումը դիտարկիչում նույն տեսքն ունի՝ լռություն։

Ահա թե ինչու յուրաքանչյուր թունելի առանձին փորձարկումը այդքան քիչ է ապացուցում։ Հանգույցի LAN հասցեն ping անելը գործարկում է առաջին որոշումը, իսկ գլխամասային գրասենյակից հանգույցը ping անելը՝ երրորդը։ Այն փաթեթը, որը ձախողվում է, որպես աղբյուր ունի օգտվողների լողավազանը և որպես նպատակակետ՝ երկրորդ տեղամասը, ուստի նախ գրեք այդ նախածանցերը։ Այստեղ լողավազանը 10.80.0.0/24 է, հանգույցի LAN-ը՝ 10.10.0.0/24, իսկ գլխամասային գրասենյակը՝ 10.20.0.0/24։

Հեռու նախածանցը հրեք հեռավոր հաճախորդին

Մի OpenVPN հեռավոր մուտքի սերվերի վրա հաճախորդը երթուղիները սովորում է միանալու պահին։ Առանց push-ի, բաժանված թունելով հաճախորդը 10.20.0.50-ը ուղարկում է իր իսկ դարպասին, և փաթեթը երբեք չի մտնում թունել։

push "route 10.20.0.0 255.255.255.0"

Հրված երթուղին ուժի մեջ է մտնում, երբ հաճախորդը միանում է, ուստի առցանց մնացող օգտվողը ոչինչ չի տեսնում, քանի դեռ նորից չի միացել։ Ստուգեք հաճախորդի վրա՝ ip route get 10.20.0.50 Linux-ում, route print Windows-ում։ Ելքը պետք է նշի թունելի ինտերֆեյսը։

push-ը չի օգնում հանգույցին։ Դա հաղորդագրություն է հաճախորդին, ոչ երթուղի սերվերի վրա և ոչ էլ վերահասցեավորման թույլտվություն, ուստի կատարյալ push տողով հանգույցը դեռ գցում է հոսքը մեկ ցատկ հետո։ Սա է սովորական պատճառը, թե ինչու մարդիկ եզրակացնում են, որ push-ը ձախողվել է։

Հանգույցին տվեք իրական ելքի երթուղի

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

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Այնտեղ, որտեղ տեղամաս-տեղամաս ոտքը ինքն է OpenVPN, երթուղին կարող է ապրել այդ կազմաձևում՝ գործընկերոջ թունելի հասցեն որպես դարպաս վերցնելով՝ route 10.20.0.0 255.255.255.0 172.30.0.2։ Դարպասը պարտադիր է։ Եթե այն բաց թողնեք, հաջորդ ցատկը ընկնում է իրականացման լռելյայն արժեքի վրա, որը տարբերվում է մեկ հեռավոր կետով հաճախորդի և բազմաթիվ գործընկերներով հանգույցի միջև։

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

Ընդարձակեք հեռավոր կողմը մինչև օգտվողների լողավազան

Գլխամասային գրասենյակն արդեն ծածկում է հանգույցի LAN-ը՝ 10.10.0.0/24։ Օգտվողների լողավազանը երկրորդ նախածանցն է և պետք է լինի նաև ընտրիչներում, այլապես ոչ մի քաղաքականություն չի ծածկում 10.80.0.25-ին ուղղված պատասխանը, և յուրաքանչյուր գործընկեր իր կողմից անվանում է նախածանցների բազմությունների նույն զույգը։

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

մի սարքի local_ts-ը մյուսի remote_ts-ն է։ Պատճենեք հանգույցի բլոկը գլխամասային գրասենյակ, և զույգը շրջվում է, ուստի դուստր SA-ն երբեք չի բարձրանում։

Ավելի հին ipsec.conf շարահյուսությունն օգտագործում է ստորակետերով բաժանված leftsubnet։ Գործող անվտանգության ասոցիացիան պահում է այն ընտրիչները, որոնց շուրջ բանակցել է, ուստի խմբագրումից հետո վերականգնեք թունելը։ 10:00-ին փոփոխված ընտրիչը, որը փորձարկվում է 09:40-ին բարձրացած SA-ի դեմ, դեռ ձախողվում է, մինչդեռ կազմաձևի ֆայլը ողջ ընթացքում ճիշտ է երևում։

Այնուհետև ստուգեք վերջին ցատկը։ Հեռավոր ծայրում ip route get 10.80.0.25-ը պետք է ցույց տա դեպի թունել։ Եթե ծառայությունն օգտագործում է LAN երթուղիչ որպես իր լռելյայն դարպաս, ապա այդ երթուղիչին նույնպես պետք է վերադարձի երթուղի, այլապես պատասխանը մահանում է այնտեղ։ tcpdump -ni eth1 host 10.80.0.25-ի գործարկումը այդ հատվածում ցույց է տալիս՝ արդյոք պատասխանը ընդհանրապես լքել է ծայրը։

Թույլատրեք հոսքը հանգույցում

Վերահասցեավորումը պետք է միացված լինի, և ուղին՝ թույլատրված։ Սահմանափակեք կանոնները երկու նախածանցերով՝ ինտերֆեյսների միջև ամեն ինչ ընդունելու փոխարեն։

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Հակադարձ ուղու զտումը դրա կողքի լուռ ձախողումն է՝ երբ երկու ոտքերը տարբեր ինտերֆեյսների վրա են, rp_filter=1-ը կարող է գցել պատասխանը, մինչ ընդունման կանոնի հաշվիչը երբեք չի շարժվում։ Համեմատեք iptables -vnL FORWARD-ը փորձից առաջ և հետո։ Կանոնին, որը երբեք չի աճում, չեն հասնում, ուստի նայեք մեկ շերտ ներքև՝ այն վերաշարադրելու փոխարեն։

Եթե անցումը պետք է միայն մեկ խմբի, երթուղին դրեք յուրաքանչյուր հաճախորդի ֆայլում՝ client-config-dir-ի ներքո, ընդհանուր push-ը լայնացնելու փոխարեն։ Source NAT-ը հանգույցում նույնպես վերացնում է հեռավոր կողմի վերադարձի երթուղու կարիքը, բայց այն թաքցնում է օգտվողի հասցեն, ուստի հեռավոր տեղամասի մատյաններն ու հասցեների վրա հիմնված կանոնները դադարում են տարբերել օգտվողներին։

Ստուգեք հաճախորդից, ապա հետ գլորեք հակառակ հերթականությամբ

Փորձարկեք TCP պորտ, ոչ միայն ICMP, որովհետև ping-ը կարող է անցնել, մինչ ծառայությունը մնում է արգելափակված։ nc -vz 10.20.0.50 445-ը և traceroute -n 10.20.0.50-ը հաճախորդից ցույց են տալիս՝ արդյոք երկրորդ ցատկը հանգույցի թունելի հասցեն է։ Հանգույցում՝ tcpdump -ni tun0 host 10.20.0.50-ը և նույն զտիչը տեղամաս-տեղամաս ինտերֆեյսում՝ հարցումը երկուսի վրա առանց պատասխանի որևէ մեկում խնդիրը տեղափոխում է հեռավոր կողմ։

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

Պահեք հետ գլորելու ցանկ, որովհետև չորս օբյեկտ փոխվել է, և երեքը հեշտ է մոռանալ՝ հրված երթուղին, հանգույցի երթուղին, ընտրիչները և հրդեհային պատի կանոնները։ Չեղարկեք դրանք հակառակ հերթականությամբ, վերականգնեք SA-ն և թույլ տվեք մեկ օգտվողի նորից միանալ։ Մասնակի հետգլորումը թողնում է երթուղի, որը ցույց է տալիս թունելի, որն այլևս չի համընկնում, և դա ավելի դժվար է կարդալ, քան սկզբնական լռությունը։ OpenVPN 2.6-ի ձեռնարկը փաստաթղթավորում է push-ը, route-ը և iroute-ը ձեր տարբերակի համար։