VPN müştərisi kimi Pi: bir menecer, yoxsa fərdi skript?

Yalnız öz çıxan trafikini qorumalı olan Raspberry Pi üçün iki real dizayn var: tunelin sahibi şəbəkə meneceri olsun, ya da tuneli idarə edən bir skript saxlayın. Hər ikisi trafiki daşıya bilər. Onlar fərqli yerlərdə sıradan çıxır və səhər iki radələrində uzaqdan diaqnoz qoya bildiyiniz nasazlıq seçməyə dəyər olandır. Onları sahiblik baxımından, IPv6 və DNS işin içinə girəndə tam tunelin nə demək olduğu baxımından və tunel düşdüyü anda nə baş verdiyi baxımından müqayisə edin.

Bir tunel üçün iki sahib

A dizaynı sistemin şəbəkə menecerinin içindəki profildir: idxal edilmiş OpenVPN profili və ya doğma WireGuard bağlantısı, yükləmə zamanı Ethernet və Wi-Fi-ı qaldıran xidmətin özü tərəfindən aktivləşdirilir. B dizaynı müştərini birbaşa işlədən, rezolver konfiqurasiyasını redaktə edən və öz marşrutlarını və firewall qaydalarını quraşdıran öz vahidinizdir. Hər ikisi qanuni dizayndır; fərq yönləndirmə cədvəlini kimin dəyişə bilməsindədir.

Nasazlıqlar fərqlidir, çünki sahiblər fərqlidir. A ilə aktivləşməyən profil interfeysi qaldırılmış, tuneli isə aşağı vəziyyətdə qoyur və menecerin jurnalları səbəbi deyir. B ilə yarımçıq uğur qazanan skript, onları yaradan prosesdən sonra da qalan marşrutlar buraxır. İkisini birlikdə işlətmək ən pis nəticədir: defolt marşrutu yazan iki proses, yükləmə zamanı yarışan iki rezolver redaktəsi və fırlanmalı iki sirlər dəsti.

Hər tunel üçün bir sahib seçin və heç nəyi sınaqdan keçirməzdən əvvəl digərini söndürün. İki sahib həm də tunel işləyərkən heç nə həll olunmadıqda baxmaq üçün iki yer deməkdir. Bu tək qayda Pi VPN müzakirələrində təsvir olunan çaşqın halların çoxunu qabaqlayır.

İdxal nə yaradır və nə yaratmır

Raspberry Pi OS Bookworm və sonrasında defolt şəbəkə konfiqurasiya aləti NetworkManager-dir, ona görə profil müştəri tuneli üçün təbii yerdir. İdxal uyğun plaqinin quraşdırılmasını tələb edir; o olmadan idxal dəstəklənməyən bağlantı növü barədə mesajla uğursuz olur ki, bu da dayanıb plaqini quraşdırmaq üçün dürüst siqnaldır.

nmcli connection import type openvpn file ./provider.ovpn
nmcli connection show
nmcli --ask connection up id provider-name

İdxal profil saxlayır. O, qarşı tərəfin əlçatan olduğunu sübut etmir və fayldakı hər direktivin çevrilmədən sağ çıxdığına zəmanət vermir. Yaranan bağlantını geri oxuyun və kimlik və etibar daşıyan hissələri yoxlayın: sertifikat, uzaq host və port, və parolun soruşulub-saxlanılmadığını.

--ask ilə aktivləşdirmə parol ifadəsini ortaq maşında shell tarixçəsindən kənarda saxlayır. Nəzarətsiz Pi üçün sonda profilin yükləmə zamanı qalxmasını istəyəcəksiniz ki, bu da onu bir dəfə əl ilə qaldırmaqdan ayrı bir qərardır.

Tam tunel, iki dizayn üzrə müqayisə

Tam tunel marşrutlar haqqında iddiadır, niyyət haqqında deyil, və iki dizayn bunu fərqli ifadə edir. Profil yanaşması menecerdən defolt marşrut və onun rezolver ayarlarını quraşdırmağı xahiş edir; skript yanaşması skriptin dediyini edir, o cümlədən heç nə. Heç bir dizayn ona tapşırılmayınca IPv6-nı əhatə etmir və toxunulmamış IPv6 defolt marşrutu IPv4 mükəmməl görünərkən trafiki məmnuniyyətlə tuneldən kənarda daşıyacaq.

ip -4 route get 198.51.100.23
ip -6 route show default
resolvectl query example.org

Marşrut axtarışı üçün sənədləşdirmə ünvanı istifadə edin və yoxlamağa icazəniz olan hostla əvəz edin. Birinci əmr Pi-nin adi təyinat üçün hansı interfeysi istifadə edəcəyini göstərir; ikincisi IPv6 defolt marşrutunun hələ də mövcud olub-olmadığını göstərir; üçüncüsü hansı rezolverin cavab verdiyini sübut edir. Tam tunel barədə hər hansı iddiaya inanmazdan əvvəl üçünü də oxuyun.

Əgər provayderin təlimatları tam tunel vəd edirsə, lakin IPv6 defolt marşrutu qalırsa, Pi sızırır. Yuxarı keçiddə IPv6-nı söndürün və ya profildən onu tələb etməsini xahiş edin və sonra aşkar etmək əvəzinə qəsdən qərar verin.

Açıq nasazlıq qapalı nasazlığa qarşı

Tunel düşdükdə defolt marşrutunu itirən yönləndirmə cədvəli sadəcə fiziki yuxarı keçidə qayıdır və trafik açıq şəkildə davam edir. Bu açıq nasazlıqdır və bir şey bunun qarşısını almadıqca hər iki dizaynın defolt davranışıdır. Çox insan bunu həftələr sonra firewall jurnalını oxuyanda kəşf edir.

Qapalı nasazlıq tunel aşağıda olanda sizə uzaqdan girişi itirdir, ona görə idarəetmə yolu üçün qəsdən istisna tələb edir. Bir üsul yalnız VPN həmyaşıdının ünvanına tuneldən kənarda icazə verən qaydadır:

sudo nft add table inet vpnkill
sudo nft 'add chain inet vpnkill out { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet vpnkill out oifname != "tun0" ip daddr != 203.0.113.24 reject

Əməliyyat xərcini dürüst müqayisə edin. Profil adətən bu qaydanı ifadə edə bilmir, ona görə qapalı nasazlıq sizi skript dizaynına və ya qaydanı tuneldən asılı olmayaraq quraşdıran kiçik vahidə doğru itələyir. Hər halda rəddləri bir həftə jurnala yazın: səssiz rədd pozulmuş xidmətlə eyni görünür və istifadəçi bir saytın yüklənməsini dayandırdığını bildirdikdə sayğaca ehtiyacınız olacaq.

Ekransız Pi üçün seçim

Əgər obraz artıq NetworkManager işlədirsə, tunel qeyri-adi heç nə tələb etmirsə və onun yuxarı keçidi avtomatik izləməsini istəyirsinizsə, profili götürün. Əgər siyasət yönləndirməsi, hər təyinat üçün seçilən bir neçə tunel və ya tunel qalxmazdan əvvəl mövcud olmalı qapalı nasazlıq qaydası lazımdırsa, skripti götürün və yükləmə sırası və təmizləmə daxil olmaqla hər hissəsinə sahib olun. İki dizaynı qarışdırmaq hər hansı birindən təkbaşına daha baha başa gəlir.

Aralarında köçmək əsasən sıra məsələsidir: köhnə sahibi söndürün, köhnə marşrut və ya rezolver qeydinin qalmadığını təsdiqləyin, sonra yenisini aktivləşdirin və iki dəfə yenidən başladın. Tək yenidən başlatma ikincisinin aşkar etdiyi yarışı gizlədə bilər. Tuneli deyil, Pi-ni sınaqdan keçirməklə bitirin: bir ad həll edin, IPv4 üzərindən nəsə alın, saxladınızsa IPv6 üzərindən alın, sonra tuneli düşürün və seçdiyiniz davranışın həqiqətən baş verdiyini təsdiqləyin. ip link içindəki interfeys sınağın başlanğıcıdır, sonu deyil.