OpenVPN հաճախորդը հասնում է սերվերին, բայց ոչ LAN հոսթերին՝ ստուգաթերթ

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

Առաջին քայլ՝ դիտեք հաճախորդի երթուղավորման որոշումը

Նախքան սերվերին դիպչելը, ապացուցեք, որ հաճախորդը փաթեթն ուղարկում է թունել։ Հարցրեք միջուկին, թե որ ինտերֆեյսը կօգտագործեր մեկ կոնկրետ LAN հոսթի համար՝ ամբողջ աղյուսակը կարդալու փոխարեն՝

ip route get 192.168.50.10

Եթե պատասխանը նշում է ձեր ֆիզիկական ադապտերը և գրասենյակի դարպասը, ապա սերվերի կողմի ոչ մի փոփոխություն չի օգնի։ OpenVPN-ը երթուղիներ բաժանում է միայն այն ժամանակ, երբ սերվերը դրանք հրում է, այնպես որ փնտրեք push "route 192.168.50.0 255.255.255.0"-ը սերվերի կոնֆիգուրացիայում և դրանից հետո նորից միացրեք հաճախորդին։ Հաճախորդների մեծ մասը հրած երթուղիները կիրառում է միանալու պահին, ոչ թե պրոֆիլը վերաբեռնելիս։

Windows-ում նույն հարցն այլ հրաման ունի։ Find-NetRoute -RemoteIPAddress 192.168.50.10-ը տպում է ինտերֆեյսը և հաջորդ թռիչքը, որը կընտրեր ստեկը, իսկ route print -4-ը ցույց է տալիս՝ արդյոք հրած նախածանցը գոյություն ունի ընդհանրապես։

Երկրորդ քայլ՝ հաստատեք, որ սերվերը կփոխանցի փաթեթը

Եթե հաճախորդի երթուղին ճիշտ է, փաթեթը հասնում է սերվերին, և սերվերը պետք է համաձայնի այն փոխանցել։ Միջուկի անջատիչը առաջին դարպասն է, և sysctl net.ipv4.ip_forward-ը պետք է վերադարձնի 1։ Այն echo 1 > /proc/sys/net/ipv4/ip_forward-ով դնելը աշխատում է մինչև հաջորդ վերագործարկումը, և հենց դա է պատճառը, որ նույն բողոքը վերադառնում է շաբաթներ անց։

Գրեք այն մի տեղ, որը կդիմանա վերագործարկմանը:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Երկրորդ դարպասը զտիչ աղյուսակն է։ Docker-ով հոսթը հաճախ ունի FORWARD քաղաքականություն DROP արժեքով, և թունելը ժառանգում է այդ որոշումը։ iptables -L FORWARD -v -n-ը ցույց է տալիս և՛ քաղաքականությունը, և՛ փաթեթների հաշվիչները՝ եթե քաղաքականությունը DROP է, փոխանցումը պահանջում է բացահայտ թույլտվություն թունելից դեպի LAN ուղղության համար և մեկը՝ պատասխանի համար։

Երրորդ քայլ՝ հետևեք փաթեթին մինչև LAN և փնտրեք պատասխանը

Դիտեք սերվերի երկու կողմերը միաժամանակ։ Ձայնագրեք թունելի և LAN ինտերֆեյսի վրա՝ զտելով մեկ հաճախորդի և մեկ հոսթի, որպեսզի ելքը մնա ընթեռնելի՝

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

tun0-ի վրա և նորից eth0-ի վրա 10.8.0.x աղբյուրով հայտնվող հարցումները, որոնց հաջորդում է լռություն, նշանակում են, որ փաթեթը հասել է, և պատասխանը գնացել է ուրիշ տեղ։ LAN հոսթը պատասխանում է իր լռելյայն դարպասին, այդ դարպասը VPN լողավազանի համար երթուղի չունի, և պատասխանը մահանում է LAN երթուղիչի վրա։ Սերվերից LAN հոսթին ping անելը ոչինչ չի ապացուցում այս ուղու մասին, որովհետև այդ տրաֆիկը երբեք չի անցնում թունելով։

Չորրորդ քայլ՝ ընտրեք թարգմանության և վերադարձի երթուղու միջև

Երկու վերանորոգում փակում են անցքը, և ընտրությունն ունի հետևանքներ այնքանով, թե արդյոք ping-ը աշխատում է։ Աղբյուրի թարգմանությունը սերվերին դարձնում է թվացյալ ուղարկող՝

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Սահմանափակեք կանոնը լողավազանով և LAN ինտերֆեյսով, ապա դարձրեք այն մշտական, այլապես հաջորդ firewall-ի վերաբեռնումը լուռ կհեռացնի ձեր ուղղումը։ Գինը ինքնությունն է՝ յուրաքանչյուր հաճախորդ LAN մատյաններում և մուտքի կանոններում նմանվում է VPN սերվերին, և per-client policy becomes guesswork։

LAN երթուղիչի վրա 10.8.0.0/24-ի համար ստատիկ երթուղին, որն ուղղված է VPN սերվերին, հաճախորդների հասցեները պահում է տեսանելի և ավելի լավ երկարաժամկետ պատասխան է, երբ այդ երթուղիչը ձերն է։ Շատ վայրեր որոշ ժամանակ երկուսն էլ են աշխատեցնում՝ NAT անհապաղ վերանորոգման համար և երթուղին, երբ firewall-ի քաղաքականությունը գրված է։ Եթե սերվերը լողավազան չէ, այլ կայքից կայք գործընկեր, ապա սերվերի կողմը նույնպես պետք է iroute հեռավոր ենթացանցի համար, այլապես գործընկերոջ երթուղին գոյություն ունի, բայց հաճախորդի տրաֆիկը երբեք չի կապվում դրա հետ։

Հինգերորդ քայլ՝ ստուգեք հաճախորդից և գրանցեք, թե ինչ փոխվեց

Փակեք շրջանակը հաճախորդից, ոչ թե սերվերից։ Միացեք LAN հոսթի իրական ծառայությանը, ապա հաստատեք, որ թարգմանության հաշվիչները շարժվել են iptables -t nat -L POSTROUTING -v -n-ով, որովհետև զրո փաթեթով կանոնը կանոն է, որը երբեք չի համապատասխանել։ conntrack -L -s 10.8.0.5-ը ցույց է տալիս հոսքը և դրա վիճակը, երբ ապացույց է պետք, որ վերադարձի ուղղությունը հետևվում է։

Սերվերի կոնֆիգուրացիայում թողեք գրառում՝ որ ենթացանցը, որ ինտերֆեյսը, որ կանոնը, և արդյոք LAN երթուղիչը վերադարձի երթուղի ունի։ Հաջորդ անգամ, երբ հաճախորդի թարմացումը ջնջի հրած երթուղին, այդ գրառումը հրդեհաշիջման սեանսը կվերածի մեկ տողով ուղղման։