NAT arxasındakı OpenVPN müştərisi necə internet çıxışına çevrilir

Üç Linux hostu, bir dizayn: ictimaiyyətə açıq OpenVPN hubı, istehlakçı noutbuku və heç nəyi içəri yönləndirməyən adi ev marşrutlaşdırıcısının arxasında oturan çıxış maşını. Çıxış huba özü qoşulur. Sonra istehlakçının internet trafiki noutbukda tunelə daxil olur və çıxışın öz yuxarı kanalından çıxır. Bu quruluşda təəccüblü olan hər şey bir detaldan irəli gəlir: əlaqəni çıxış başlatdı, ona görə içəri yol artıq mövcuddur və onu yaratmaq üçün port yönləndirməsi lazım deyil.

Aşağıdakılar konfiqurasiya sırasını deyil, paket yolunu izləyir, çünki konfiqurasiya yalnız hansı komponentin hansı qərarı verdiyini bildikdən sonra məna kəsb edir. Hər təbəqə düz bir qərar verir və səhvlər iki təbəqənin eyni təbəqə sayıldığı yerdə toplanır.

İki nəqliyyat sessiyası, bir daxili yol

Hər host huba öz xarici bağlantısını saxlayır və bu bağlantılardan heç biri digərini bilmir. İstehlakçının internetə trafiki ayrı, daxili axındır: təsadüfən istehlakçının tuneli içində daşınır və sonra çıxışın tunelindən yenidən buraxılır. Hub məhz bu daxili axını marşrutlaşdırmalıdır və çıxış məhz onu yönləndirməlidir.

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

Hər iki xarici bağlantı müştəri tərəfindən xaricə getdiyi üçün çıxışın marşrutlaşdırıcısı heç vaxt gələn SYN görmür və heç vaxt təyinat NAT qaydasına ehtiyac duymur. O, yalnız qurulmuş nəqliyyatı canlı saxlamalıdır, bunu isə hər uzunmüddətli bağlantı üçün artıq edir. Açıq internetdə heç nə əvvəlcə çıxışa çatmalı deyil, buna görə də həmin yuxarı kanaldakı dinamik ünvan problem deyil. Marşrutlaşdırıcı hələ də xarici sessiyaya icazə verməlidir, amma bu, brauzerin artıq istifadə etdiyi icazənin eynisidir.

iroute serverin içində əslində nə quraşdırır

Hub hansı peerin hansı təyinatı sahibləndiyini təyin edən yeganə cihazdır və bu qərarı nüvənin deyil, öz istifadəçi sahəsi marşrut cədvəlində verir. Çıxış üçün exit-node adlı client-config-dir girişi orada standart prefiksi iddia edə bilər:

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

Bu sətir server prosesinə "hər hansı təyinatlı daxili paketlər bu müştəriyə aiddir" deyir. O, hubın əməliyyat sisteminə standart marşrut əlavə etmir və hubı internet şlüzünə çevirmir. OpenVPN 2.6 sənədi müştəriyə xas daxili marşrutlaşdırma ilə nüvə marşrutlaşdırmasını ayrı mexanizmlər kimi saxlayır və bu ayrılıq bu dizaynın hubın standart marşrutuna toxunmadan işləməsinin səbəbidir.

İstehlakçıya güzgü kimi tərs təlimat lazımdır, push kimi çatdırılır, belə ki öz trafiki yerli şlüzdən çıxmaq əvəzinə tunelə daxil olsun. Alt şəbəkə topologiyasında hovuz çıxışın tun cihazında birləşdirilmiş marşrutdur, ona görə geri istiqamət əlavə push tələb etmir; çıxışın almamalı olduğu şey aşağıdakı yönləndirmədir, o, öz yuxarı kanal trafikini istifadə etməyə çalışdığı tunelə geri göndərərdi. Onu yalnız istehlakçıya göndərin və tətbiq olunan marşrutları müştəridə oxuyun, CCD faylının seçildiyinə güvənməyin.

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

Yönləndirməni çıxışın nüvəsi edir

Çıxışın içində istehlakçıdan gələn paket tun interfeysinə hansısa internet hostuna ünvanlanmış şəkildə gəlir. Nüvə öz marşrut cədvəlinə baxır, ən yaxşı uyğunluq kimi real yuxarı kanalı tapır və sonra iki müstəqil siyasət tətbiq edir: bu paket ümumiyyətlə yönləndirilə bilərmi və həmin mənbə ünvanı ilə həmin interfeysdən çıxa bilərmi. Yönləndirmə sysctl-dir və bir çox distributivdə standart olaraq söndürülüb.

Deməli, çıxışa davamlı aktiv IPv4 yönləndirməsi, istehlakçının tunel mənbələrini yuxarı kanala buraxan yönləndirmə qaydası və tun vasitəsilə geri cavab yolu lazımdır. Bütün host üçün yönləndirməni aktivləşdirmək ondan keçən hər şeyin davranışını da dəyişir, buna görə qayda hər şeyi qəbul etmək əvəzinə mənbələri və interfeysləri adlandırmalıdır.

Geri yolu mənbə tərcüməsi alır

İnternet hostunun 10.90.0.x ünvanına marşrutu yoxdur, ona görə cavablar çıxışa çatmadan atılardı. Paket yuxarı kanaldan çıxarkən mənbəni yenidən yazmaq bunu həll edir və bağlantı izləmə geri yolda yenidən yazmanı tərsinə çevirir.

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

Yuxarıdakı qayda bir yuxarı kanal interfeysi üçün başlanğıc nöqtəsidir, firewall siyasəti deyil. Mənbəni həqiqətən icazə verdiyiniz təyinatlaradək daraldın və çıxışın öz giriş siyasətini ayrı saxlayın ki, tunel trafiki üçün masquerading yerli xidmətləri səssizcə ifşa etməsin. Dinamik yuxarı kanal ünvanı olan hostda masquerade sizi ünvanı əl ilə izləməkdən də xilas edir.

Hub harada tətbiq edə bilər, harada bilməz

client-to-client və ənənəvi istifadəçi sahəsi məlumat yolu ilə hub daxili paketləri server prosesinin içində peerlər arasında ötürür. Onlar heç vaxt hubın nüvə FORWARD zəncirindən keçmir, ona görə oradakı nüvə qaydası nə qədər diqqətlə yazılsa da peer-to-peer keçidi məhdudlaşdıra bilməz. Tətbiq serverin öz siyasətində yaşamalıdır: kimin qoşulmasına icazə var, hansı CCD faylını alır və çıxışın standart sahibliyi ümumiyyətlə verilirmi.

Buna görə də standart iroute geniş etimad qərarıdır. Çıxış ixtiyari internet ünvanlarından geri trafiki qanuni olaraq qəbul etməlidir və o, nəzarət etdiyiniz, yamaqlanmış və izlənən maşın olmalıdır. Eyni sahibliyi marşrutlaşdırıcı verməyəcəyiniz bir peerə vermək bu dizaynın dəvət etdiyi səhvdir.

Üzvlük əsl idarəetmədir. Öz marşrutlarını konfiqurasiya edə bilən hər müştəri çıxışdan istifadə etməyə cəhd edə bilər, ona görə kimin qoşula biləcəyini və ya çıxışın hansı peerlərə xidmət edəcəyini məhdudlaşdırmaq sonradan düşünülən deyil, dizaynın bir hissəsidir.

Çıxış yox olduqda təhlükəsiz sıradan çıxma

Çıxışı oflayn çıxarın və daxili standart sahiblik öz sessiyası ilə birlikdə yox olur. Baş verməməli olan odur ki, hub səssizcə əvəzedici çıxışa çevrilsin: VPN hovuzundan hubın yuxarı kanalına standart marşrut olmasın və hubda eyni trafiki məmnuniyyətlə yönləndirəcək geniş masquerade qaydası olmasın. Bu nasazlığı qəsdən sınaqdan keçirin, sonra bərpanı artıq açıq olan səhifə ilə deyil, təzə axınla yoxlayın.

# 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

Əgər çıxış getdikdən sonra istehlakçının trafiki hələ də internetə çatırsa, onu başqa bir şey daşıyır və nəzərdə tutduğunuz sərhəd mövcud deyil. DNS və IPv6-nı da ayrı qərarlar kimi idarə edin: IPv4 marşrutu üstəgəl masquerade AAAA trafiki haqqında heç nə demir və hub tərəfindən göndərilən resolver sorğunun həqiqətən çıxdığı yerdən cavab verəcək.