Լիաթունել OpenVPN՝ ավելացրեք ինտերնետ ելք սերվերի կողմում

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

Մղեք լռելյայն երթուղին և հաստատեք, թե ինչ է տեղադրել հաճախորդը

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

push "redirect-gateway def1"

Վերակապվելուց հետո կարդացեք հաճախորդի երթուղային աղյուսակը՝ պրոֆիլին վստահելու փոխարեն։ Linux-ում երկու /1 գրառումները հայտնվում են սկզբնական լռելյայնի կողքին, իսկ Windows-ը ցույց է տալիս նույն զույգը որպես 0.0.0.0/1 և 128.0.0.0/1։ Հաճախորդը, որը անտեսում է մղված ընտրանքները, կամ որը կարգավորված է դրանք մերժելու, պահում է իր հին լռելյայնը և երբեք ինտերնետ տրաֆիկ չի ուղարկում թունել։ Լուծեք այս հարցը նախքան սերվերի վրա որևէ բան փոխելը, որովհետև սերվերի կողմի ոչ մի կանոն չի կարող փոխհատուցել։

Փոխանցումը սերվերի կարգավորում է, ոչ VPN-ի

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

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

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

Թույլատրեք հենց այն անցումը, որը նկատի ունեք, և ոչ այլ բան

Փոխանցված փաթեթներն անցնում են forward ուղով; VPN-հոսթին հասցեագրված տրաֆիկը անցնում է input ուղով։ Սրանք տարբեր որոշումներ են, և input ուղը բացելը չի թույլատրում մեքենայով անցումը։ Դրանք շփոթելը ամենատարածված պատճառն է, թե ինչու ֆայրվոլը կարծես ամեն ինչ թույլատրում է, մինչ հաճախորդները դեռ ժամանակի սպառում են ստանում։

Նվազագույն քաղաքականությունը ընդունում է նոր կապեր լողավազանից դեպի ելքային ինտերֆեյս և ընդունում է պատասխաններ, որոնք պատկանում են հաստատված հոսքերին։ Տեղադրեք այն այն կանոնների հավաքածուի տիրոջ մեջ, որն օգտագործում է ձեր տարածումը, փոխարենը յուրաքանչյուր բեռնման ժամանակ կրկնվող կանոն ավելացնելուց; կրկնվող կանոնները կուտակվում են, և հաշվիչները դադարում են իմաստ ունենալ։

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

Տվեք պատասխաններին տեղ, ուր գնան

Լողավազանի հասցեները մասնավոր են, ուստի հանրային սերվերը չի կարող պատասխանն ուղղակիորեն հասցնել դրանց։ Կամ VPN-հոսթը թարգմանում է աղբյուրի հասցեն ելքի ճանապարհին, կամ վերին սարքը պահում է երթուղի դեպի լողավազան։

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

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

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

Ապացուցեք դա հաճախորդից, ոչ սերվերի կեղևից

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

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Գրանցեք փոփոխությունները և հետարկման քայլը ընթացքում, որպեսզի ելքի քաղաքականությունը հնարավոր լինի վերադարձնել մեկ գործողությամբ, երբ փորձարկումը ձախողվի։ Այս բաղադրատոմսը ընդգրկում է միայն IPv4; առանձին գույքագրեք IPv6-ը նախքան պնդելը, որ տեղակայումը կրում է ողջ տրաֆիկը։