Raspberry Pi VPN şlüzü: bir şəbəkə portu, yoxsa ayrı müştəri portu
Bir Pi portu seçilmiş müştərilərə xidmət edə bilər, ya da ikinci port cihazları içəridə saxlaya bilər. Sxemi təcrid, ehtiyat siyasəti və DNS-in kimə aid olduğuna görə seçin.
Sizin bir Raspberry Pi, işlək bir çıxan VPN profili və onun vasitəsilə internetə çıxmalı olan iki cihazınız var. Bütün quruluşu həll edən sual hansı təlimata əməl etmək deyil, nə qədər təcridə ehtiyacınız olduğudur. Tək port Raspberry Pi-nin həmin cihazların yanında marşrutlaşdırıcının LAN-da oturmasına və əlavə şlüz kimi çıxış etməsinə imkan verir; ikinci port isə onları Raspberry Pi-nin yeganə çıxış olduğu seqmentə yerləşdirməyə imkan verir. Bu seçimdən sonra gələn hər şey — DHCP, firewall əhatəsi, DNS, kəsinti halı — ondan irəli gəlir.
İki sxem əslində nə ilə fərqlənir
Hər iki dizayn marşrutlaşdırır. Fərq kabeldə başqa kimin durması və siyasətiniz səhv olduqda nə baş verməsidir.
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
Əsl ox təcriddir. A sxemi məsləhət xarakteri daşıyır: DHCP ilə verilən şlüzü görməzlikdən gəlib marşrutlaşdırıcını seçən cihaz yenə də şifrəsiz işləyir. B sxemi topologiya ilə tətbiq edilir, çünki seçiləcək başqa növbəti keçid yoxdur.
A sxemi: Raspberry Pi mövcud LAN-da əlavə şlüz kimi
Tutaq ki, ISP marşrutlaşdırıcısı 192.168.50.1, Raspberry Pi 192.168.50.2-dir və seçilmiş müştərilər Raspberry Pi-yə baxır. Vacib olan odur ki, iki fərqli paket axını bir kabeli paylaşır. Müştərinin daxili paketi Raspberry Pi-yə gəlir və tuneldən çıxmalıdır; Raspberry Pi-nin VPN həmyaşısına gedən öz şifrəli paketi isə həmin kabeldən marşrutlaşdırıcıya çıxmalıdır. Onlar eyni interfeysdən əks istiqamətlərdə hərəkət edir və fərqli rəftar tələb edir.
Raspberry Pi-yə ünvanını cihaz uğrunda onunla mübarizə aparan köhnə interfeys faylı reseptindən deyil, quraşdırılmış şəbəkə menecerindən verin. Sonra müştəriləri qurun: bir cihazda statik şlüz, ya da 192.168.50.2-ni marşrutlaşdırıcı kimi paylayan DHCP rezervasiyası. İki cihaz üçün marşrutlaşdırıcının bütün DHCP diapazonunu dəyişməyin və müştərinin bu seçimə hörmət etdiyini güman etməyin — bunu yoxlayın.
Zəiflik quruluşdan irəli gəlir, düzəldilə bilən deyil. O seqmentdəki istənilən müştəri 192.168.50.1-ə baxıb şifrəsiz çıxa bilər və ikinci interfeysi və ya mobil radiosu olan cihaz sizin tətbiq yolunuzdan tamamilə çıxır. Əgər bu cümlə sözügedən cihaz üçün qəbuledilməzdirsə, cavabınız artıq var: B sxemindən istifadə edin.
B sxemi: ayrılmış port cihazları içəridə saxlayır
Burada Raspberry Pi uplinkdə şlüz 192.168.50.1 ilə 192.168.50.2-ni saxlayır və qoşulmuş cihazlar üçün ikinci interfeysdə 10.20.0.1/24 alır. İndi Raspberry Pi iki şəbəkəli marşrutlaşdırıcıdır və qoşulmuş seqmentin tam bir çıxışı var.
Diapazonu hər şeylə tutuşdurmadan əvvəl yoxlayın: tunelin öz subneti, digər sahə-sahə prefiksləri və VPN vasitəsilə əlçatan olan hər şey. Uzaq LAN ilə toqquşan 10.20.0.0/24 bir axşam diaqnoz tələb edən yarımçıq nəticə verir. İkinci port USB adapterdirsə, onun dəstəkləndiyini təsdiqləyin və adını şəbəkə menecerində bərkidin ki, yenidən başlatmadan sonra sıralama dəyişikliyi LAN ünvanınızı yerindən tərpətməsin.
DHCP dinləyicisini yalnız həmin interfeysdə işlədin. Uplinkdə cavab verən server ISP marşrutlaşdırıcısı ilə rəqabət edir və seqmentinizin ünvanlarını evin qalan hissəsinə paylayır. Onu LAN interfeysinə bağlayın, elan edilmiş diapazonla məhdudlaşdırın və Raspberry Pi-nin öz ünvanını hovuzdan kənarda saxlayın.
Yönləndirmə, tərcümə və uğursuzluqda bağlanma qaydası
Dörd şey çox vaxt bir şey kimi təsvir olunur və elə deyil. Yönləndirməni aktivləşdirmək (net.ipv4.ip_forward=1) kernelə yalnız interfeyslər arasında paket köçürə biləcəyini söyləyir; özlüyündə heç nəyə icazə vermir və heç bir yol zəmanət etmir. Çıxışı seçmək marşrut qərarıdır. Paketə icazə vermək forward zəncirində siyasət qərarıdır. Onun mənbəyini yenidən yazmaq postrouting qərarıdır. Yalnız birincisini edən quruluş, müştəri trafikini məmnuniyyətlə uplinkdən yönləndirən bir Raspberry Pi yaradır.
İcazəni nəzərdə tutduğunuz mənbələrlə və trafikin istifadə etməli olduğu interfeyslə məhdudlaşdırın, qayıdış yolunu və Raspberry Pi-nin özünə lazım olan təyinatları da daxil edin. Sonra provayder LAN prefiksinizi sizə geri marşrutlaşdırmırsa, tunel çıxışında tərcümə edin. nftables təlimatı yönləndirməni, lokal çıxışı və mənbə tərcüməsini ayrı əməliyyatlar kimi qəbul edir, bu da burada düzgün düşüncə modelidir.
Ümumi uğursuzluq fiziki interfeysdə geniş masquerade qaydasıdır. Onda trafik ISP yolu ilə internetə çatır, halbuki müştəri tərəfindən tam işlək VPN kimi görünür. Bu heç nə sübut etmir. Tərcüməni elan edilmiş çıxışa bağlı saxlayın və qaydalarınızı hostun artıq istifadə etdiyi firewall-da saxlayın, paylaşılan postrouting zəncirini boşaldan rəqib qaydalar toplusu əlavə etməyin.
Sonra tunelin olmamasını həll edin. Geniş default marşrut quraşdıran müştəri profili həm də o deməkdir ki, tunel düşəndə adi default geri qayıda bilər və müştəri trafiki səssizcə uplinkə qayıdır. Açıq mətnlə ehtiyat yolun qəbuledilməz olduğu yerlərdə, forward siyasəti müştəridən uplinkə trafiki açıq şəkildə rədd etməlidir, VPN marşrutunun getdiyi vəziyyətdə. Bunu fərziyyə kimi deyil, rədd qaydası kimi yazın. Raspberry Pi-nin VPN həmyaşına öz şifrəli nəqli ayrı local-output axınıdır və icazəli qalmalıdır, əks halda tunel heç vaxt geri qayıda bilməz.
DNS və IPv6 öz cavabını tələb edir
Müştərilər Raspberry Pi-ni həlledici kimi istifadə edirsə, onlar lokal dinləyiciyə çatır və Raspberry Pi yeni sorğu yaradır. Həmin yuxarı sorğu müştərilər üçün yazdığınız forward qaydasına deyil, Raspberry Pi-nin öz marşrutuna uyğun gedir, buna görə yalnız tuneldən gedən müştəri yolu üstəgəl birbaşa çıxan həlledici heç bir xəta mesajı olmayan sızıntıdır. Qəsdən qərar verin: tunel üzərindən çatılan həlledici, yoxsa birbaşa qəbul etdiyiniz lokal həlledici, və Raspberry Pi-nin öz çıxış siyasətini bu qərara uyğunlaşdırın.
IPv6 yenidən ayrıdır. IPv4 üçün forward qaydası IPv6 ilə bağlı heç nəyi məhdudlaşdırmır və uplinkdəki router reklamları Raspberry Pi-yə, onun vasitəsilə də qoşulmuş seqmentə siyasətinizi yan keçən ikinci default verə bilər. Ya IPv6-ya eyni prinsiplə öz qorunan yolunu verin, ya da onu müştəri seqmentində açıq şəkildə məhdudlaşdırın və bunu deyin.
Etibarlı saymadan əvvəl sərhədi sınayın
Dizaynı yalnız dörd ayrı yoxlamadan sonra qəbul edin, çünki cəlbedici tək test — bir müştəridə brauzer açmaq — bir neçə pozulmuş vəziyyətdə keçir.
Bir real müştərinin tunel vasitəsilə internetə çatdığını təsdiqləyin, sonra həmin müştərinin tunel söndürüldükdə internetə çıxa bilmədiyini təsdiqləyin. DNS həllinin işlədiyini və sorğunun nəzərdə tutduğunuz yerdən çıxdığını təsdiqləyin. Tunel yenidən başladıqdan sonra Raspberry Pi-nin öz nəqlinin hələ də işlədiyini və bərpanın cihazın yenidən başladılmasını tələb etmədiyini təsdiqləyin. Nəhayət, seçmədiyiniz bir cihazı yoxlayın: A sxemində o, normal işləməyə davam etməlidir, B sxemində isə o seqmentdə ümumiyyətlə olmamalıdır.
- İki port və rədd qaydası tətbiq verir; bir port və DHCP seçimi məsləhət verir.
- Səhv interfeysdə tərcümə uğur kimi görünür və uğur deyil.
- Raspberry Pi-nin öz trafiki, DNS və IPv6 hər biri qərar tələb edir, nəticə çıxarma deyil.