Ինչպես NAT-ի հետևում գտնվող OpenVPN հաճախորդը դառնում է ինտերնետի ելք

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

Հետևյալը հետևում է փաթեթի ուղուն, ոչ թե կարգաբերման հերթականությանը, քանի որ կարգաբերումը իմաստ ունի միայն այն ժամանակ, երբ գիտեք, թե որ բաղադրիչն որ որոշումն է կայացնում։ Յուրաքանչյուր շերտ կայացնում է ուղիղ մեկ որոշում, և սխալները կուտակվում են այնտեղ, որտեղ երկու շերտ համարվում են մեկը։

Երկու տրանսպորտային սեսիա, մեկ ներքին ուղի

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

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

Քանի որ երկու արտաքին կապերն էլ դուրս են գալիս հաճախորդի կողմից, ելքի երթուղիչը երբեք մուտքային SYN չի տեսնում և երբեք նպատակակետային NAT կանոնի կարիք չունի։ Նրան միայն պետք է հաստատված տրանսպորտը կենդանի պահել, ինչը նա արդեն անում է ցանկացած երկարատև կապի համար։ Հանրային ինտերնետում ոչինչ պետք չէ նախ հասնի ելքին, դրա համար էլ այդ վերին կապի դինամիկ հասցեն խնդիր չէ։ Երթուղիչը դեռ պետք է թույլատրի արտագնա սեսիան, բայց դա նույն թույլտվությունն է, որն արդեն օգտագործում է դիտարկիչը։

Ինչ է իրականում տեղադրում iroute-ը սերվերի ներսում

Հանգույցը միակ սարքն է, որը որոշում է, թե որ գործընկերն որ նպատակակետին է տիրապետում, և այդ որոշումը կայացնում է իր օգտվողական տարածության երթուղային աղյուսակում, ոչ թե միջուկի։ Ելքի համար exit-node անունով client-config-dir գրառումը կարող է այնտեղ պահանջել լռելյայն նախածանցը՝

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

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

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

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

Փոխանցումը կատարում է ելքի միջուկը

Ելքի ներսում սպառողի փաթեթը հասնում է tun ինտերֆեյսին՝ ուղղված ինչ-որ ինտերնետ հոսթի։ Միջուկը դիտում է իր երթուղային աղյուսակը, գտնում է իրական վերին կապը որպես լավագույն համընկնում և ապա կիրառում երկու անկախ քաղաքականություն՝ թույլատրվա՞ծ է այս փաթեթը ընդհանրապես փոխանցել, և թույլատրվա՞ծ է այն լքել այդ ինտերֆեյսով այդ աղբյուրի հասցեով։ Փոխանցումը sysctl է, և շատ տարածումներում այն լռելյայն անջատված է։

Այսպիսով ելքին պետք է մշտապես միացված IPv4 փոխանցում, կանոն, որը թույլ է տալիս սպառողի թունելի աղբյուրները դեպի վերին կապ, և պատասխանի ուղին՝ հետ tun-ով։ Փոխանցումը ամբողջ հոսթի համար միացնելը փոխում է նաև նրա միջով երթուղավորվող ամեն ինչի վարքը, դրա համար էլ կանոնը պետք է նշի աղբյուրներն ու ինտերֆեյսները՝ ամեն ինչ ընդունելու փոխարեն։

Վերադարձի ուղին գնում է աղբյուրի թարգմանությամբ

Ինտերնետ հոսթը 10.90.0.x հասցեին երթուղի չունի, ուստի պատասխանները կմերժվեին մինչև ելք հասնելը։ Աղբյուրը վերաշարադրելը, երբ փաթեթը լքում է վերին կապը, լուծում է դա, և կապերի հետևումը հակադարձում է վերաշարադրումը վերադարձին։

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

Վերևի կանոնը սկզբնակետ է մեկ վերին ինտերֆեյսի համար, ոչ թե հրապատի քաղաքականություն։ Նեղացրեք աղբյուրը ձեր իրականում լիազորած նշանակումներով, և ելքի սեփական մուտքային քաղաքականությունը պահեք առանձին, որպեսզի թունելի երթևեկության քողարկումը լուռ չբացահայտի տեղական ծառայությունները։ Դինամիկ վերին հասցե ունեցող հոսթում քողարկումը ձեզ ազատում է նաև հասցեն ձեռքով հետևելուց։

Որտեղ հանգույցը կարող է պարտադրել և որտեղ՝ ոչ

client-to-client-ով և ավանդական օգտվողական տարածության տվյալների ուղով հանգույցը ներքին փաթեթները գործընկերների միջև հանձնում է սերվերի գործընթացի ներսում։ Դրանք երբեք չեն անցնում հանգույցի միջուկի FORWARD շղթայով, ուստի այնտեղի միջուկի կանոնը չի կարող սահմանափակել գործընկերների միջև անցումը, ինչքան էլ զգույշ գրված լինի։ Պարտադրումը պետք է ապրի սերվերի սեփական քաղաքականության մեջ՝ ով կարող է միանալ, որը CCD ֆայլն է ստանում և արդյոք ելքի լռելյայն տիրապետումն ընդհանրապես տրվում է։

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

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

Անվտանգ ձախողում, երբ ելքը անհետանում է

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

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Եթե սպառողի երթևեկությունը ելքի անհետանալուց հետո էլ հասնում է ինտերնետ, ուրեմն այն կրում է մեկ այլ բան, և ձեր նախատեսած սահմանը գոյություն չունի։ DNS-ը և IPv6-ը նույնպես վերաբերվեք որպես առանձին որոշումների՝ IPv4 երթուղին գումարած քողարկումը ոչինչ չի ասում AAAA երթևեկության մասին, և հանգույցի կողմից ուղարկված լուծիչը կպատասխանի այնտեղից, որտեղից հարցումն իրականում դուրս է գալիս։