VPN istemcisi olarak Pi: tek bir yönetici mi, kendi betiğiniz mi?

Yalnızca kendi giden trafiğini koruması gereken bir Raspberry Pi'nin iki gerçekçi tasarımı vardır: tüneli ağ yöneticisine sahiplendirmek ya da onu sahiplenen bir betik tutmak. İkisi de trafik taşıyabilir. Farklı yerlerde başarısız olurlar ve gece ikide uzaktan teşhis edebildiğiniz arıza seçilmeye değer olandır. Onları sahiplik, IPv6 ve DNS işin içine girdiğinde tam tünelin ne anlama geldiği ve tünelin düştüğü anda ne olduğu açısından karşılaştırın.

Bir tünele iki sahip

Tasarım A, sistemin ağ yöneticisinin içindeki bir profildir: içe aktarılmış bir OpenVPN profili veya yerel bir WireGuard bağlantısı; açılışta Ethernet ve Wi-Fi'yi kaldıran aynı hizmet tarafından etkinleştirilir. Tasarım B, istemciyi doğrudan çalıştıran, çözümleyici yapılandırmasını düzenleyen ve kendi rotalarını ve güvenlik duvarı kurallarını kuran kendi biriminizdir. İkisi de meşru tasarımdır; yönlendirme tablosunu kimin değiştirebileceği konusunda ayrılırlar.

Arızalar farklıdır çünkü sahipler farklıdır. A'da etkinleşmeyen bir profil arayüzü yukarıda, tüneli aşağıda bırakır ve yöneticinin günlükleri nedenini söyler. B'de yarı başarılı olan bir betik, onları oluşturan süreç bittikten sonra da kalan rotalar bırakır. İkisini birden çalıştırmak en kötü sonuçtur: iki süreç varsayılan rotayı yazar, açılışta iki çözümleyici düzenlemesi yarışır ve iki gizli dizi döndürülmelidir.

Her tünel için tek sahip seçin ve bir şeyi test etmeden önce diğerini devre dışı bırakın. İki sahip, tünel yukarıdayken hiçbir şey çözülemediğinde bakılacak iki yer demektir de. Bu tek kural, Pi VPN başlıklarında anlatılan kafa karıştırıcı durumların çoğunu önler.

İçe aktarma ne yaratır, ne yaratmaz

Raspberry Pi OS Bookworm ve sonrasında varsayılan ağ yapılandırma aracı NetworkManager'dır, bu yüzden profil istemci tünelinin doğal evidir. İçe aktarma eşleşen eklentinin kurulu olmasını gerektirir; o yoksa içe aktarma desteklenmeyen bağlantı türüne ilişkin bir iletiyle başarısız olur, bu da durup eklentiyi kurmanın dürüst işaretidir.

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

İçe aktarma bir profil saklar. Karşı tarafın erişilebilir olduğunu kanıtlamaz ve dosyadaki her yönergenin dönüşümden sağ çıktığını garanti etmez. Ortaya çıkan bağlantıyı geri okuyun ve kimlik ile güveni taşıyan parçaları denetleyin: sertifika, uzak ana makine ve bağlantı noktası ve parolanın sorulup sorulmadığı ya da saklanıp saklanmadığı.

--ask ile etkinleştirme, paylaşılan bir makinede parola ifadesini kabuk geçmişinin dışında tutar. Gözetimsiz bir Pi için eninde sonunda profilin açılışta yükselmesini istersiniz; bu, onu elle bir kez kaldırmaktan ayrı bir karardır.

Tam tünel, iki tasarım üzerinden karşılaştırma

Tam tünel, niyetle değil rotalarla ilgili bir iddiadır ve iki tasarım bunu farklı ifade eder. Profil yaklaşımı yöneticiden varsayılan bir rota ve çözümleyici ayarlarını kurmasını ister; betik yaklaşımı betiğin söylediğini yapar, hiçbir şey yapmamak dahil. Hiçbir tasarım kendisine söylenmedikçe IPv6'yı kapsamaz ve dokunulmamış IPv6 varsayılan rotası, IPv4 kusursuz görünürken trafiği tünelin dışına memnuniyetle taşır.

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

Rota sorgusu için belge amaçlı bir adres kullanın ve onu denetlemenize izin verilen bir ana makineyle değiştirin. İlk komut Pi'nin sıradan bir hedef için hangi arayüzü kullanacağını, ikincisi bir IPv6 varsayılan rotasının hâlâ var olup olmadığını gösterir; üçüncüsü hangi çözümleyicinin yanıt verdiğini kanıtlar. Tam tünel hakkındaki herhangi bir iddiaya inanmadan önce üçünü de okuyun.

Sağlayıcının talimatları tam tünel vaat ediyor ama IPv6 varsayılan rotası varlığını sürdürüyorsa Pi sızdırıyordur. Yukarı bağlantıda IPv6'yı devre dışı bırakın ya da profilden bunu talep etmesini isteyin ve sonradan keşfetmek yerine bilinçli karar verin.

Açık arıza ile kapalı arıza

Tünel düştüğünde varsayılan rotasını kaybeden yönlendirme tablosu basitçe fiziksel yukarı bağlantıya geri döner ve trafik açıkta devam eder. Bu açık arızadır ve bir şey engellemedikçe iki tasarımın da varsayılan davranışıdır. Çoğu insan bunu haftalar sonra bir güvenlik duvarı günlüğünü okuyunca fark eder.

Kapalı arıza, tünel aşağıdayken uzaktan erişiminizi alır, bu yüzden yönetim yolu için bilinçli bir istisna gerekir. Bir yol, tünelin dışında yalnızca VPN eşinin adresine izin veren bir kuraldı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

İşletme maliyetini dürüstçe karşılaştırın. Profil genellikle bu kuralı ifade edemez, bu yüzden kapalı arıza sizi betik tasarımına ya da kuralı tünelden bağımsız kuran küçük bir birime iter. Her durumda reddetmeleri bir hafta günlüğe kaydedin: sessiz bir ret, bozuk bir hizmetle tamamen aynı görünür ve bir kullanıcı bir sitenin yüklenmeyi bıraktığını bildirdiğinde sayaca ihtiyacınız olacaktır.

Ekransız Pi için seçim

İmaj zaten NetworkManager çalıştırıyorsa, tünel egzotik bir şey gerektirmiyorsa ve yukarı bağlantıyı otomatik izlemesini istiyorsanız profili seçin. İlke yönlendirmesi, hedefe göre seçilen birkaç tünel veya tünel kalkmadan önce var olması gereken kapalı arıza kuralı gerekiyorsa betiği seçin ve açılış sırası ile temizlik dahil her parçasına sahip olun. İki tasarımı karıştırmak, her birinden tek başına daha pahalıdır.

Aralarında geçiş çoğunlukla sıra meselesidir: eski sahibi devre dışı bırakın, eski bir rotanın veya çözümleyici girdisinin kalmadığını doğrulayın, sonra yenisini etkinleştirin ve iki kez yeniden başlatın. Tek bir yeniden başlatma, ikincisinin açığa çıkardığı bir yarışı gizleyebilir. Tüneli değil Pi'yi test ederek bitirin: bir adı çözün, IPv4 üzerinden bir şey alın, tuttuysanız IPv6 üzerinden de alın, sonra tüneli düşürün ve seçtiğiniz davranışın gerçekten gerçekleştiğini doğrulayın. ip link içindeki arayüz testin başlangıcıdır, sonu değil.