Raspberry Pi'de VPN ağ geçidi: tek ağ kartı mı, ayrı bir istemci portu mu

Bir Pi'niz, çalışan bir giden VPN profiliniz ve onun üzerinden internete çıkması gereken iki cihazınız var. Bütün kurulumu belirleyen soru hangi kılavuzu izleyeceğiniz değil, ne kadar kuşatmaya ihtiyacınız olduğudur. Tek port, Pi'nin o cihazların yanında yönlendiricinin LAN'ında durmasına ve ek bir ağ geçidi olarak çalışmasına izin verir; ikinci bir port ise onları Pi'nin tek çıkış olduğu bir segmentte konumlandırmanızı sağlar. Bu seçimden sonraki her şey — DHCP, güvenlik duvarının kapsamı, DNS, kesinti durumu — bundan doğar.

İki düzen gerçekte neyle ayrışır

İki tasarım da yönlendirme yapar. Fark, kabloda başka kimin durduğu ve politikanız yanlış olduğunda ne olacağıdır.

Gerçek eksen kuşatmadır. Düzen A tavsiye niteliğindedir: DHCP'nin verdiği ağ geçidini yok sayıp yönlendiriciyi seçen cihaz şifreleme olmadan da çalışır. Düzen B topoloji tarafından zorlanır, çünkü seçilecek başka bir sonraki atlama yoktur.

Düzen A: Pi, mevcut LAN'da ek bir ağ geçidi olarak

ISP yönlendiricisinin 192.168.50.1, Pi'nin 192.168.50.2 olduğunu ve seçilen istemcilerin Pi'yi işaret ettiğini varsayalım. Önemli olan, iki farklı paket akışının tek bir kabloyu paylaşmasıdır. İstemcinin iç paketi Pi'ye ulaşır ve tünelden dışarı çıkmalıdır; Pi'nin kendi şifreli paketi VPN eşine aynı kablodan yönlendiriciye doğru çıkmalıdır. Aynı arayüz üzerinde zıt yönlerde hareket ederler ve farklı işlem gerektirirler.

Pi'ye adresini kurulu ağ yöneticisi üzerinden verin, cihaz için onunla rekabet eden eski bir arayüz dosyası tarifinden değil. Sonra istemcileri ayarlayın: bir cihazda statik ağ geçidi ya da 192.168.50.2'yi yönlendirici olarak dağıtan bir DHCP rezervasyonu. İki cihaz için yönlendiricinin tüm DHCP kapsamını değiştirmeyin ve istemcinin bu seçeneğe uyduğunu varsaymayın — doğrulayın.

Zayıflık yapısaldır, onarılamaz. O segmentteki herhangi bir istemci 192.168.50.1'i işaret edip açık metin olarak çıkabilir ve ikinci bir arayüze veya hücresel radyoya sahip bir cihaz uygulama yolunuzu tamamen terk eder. Bu cümle söz konusu cihaz için kabul edilemezse yanıtınız zaten var: düzen B'yi kullanın.

Düzen B: ayrı bir port cihazları içeride hapseder

Burada Pi, yukarı bağlantıda 192.168.50.1 ağ geçidiyle 192.168.50.2'yi korur ve bağlı cihazlar için ikinci arayüzde 10.20.0.1/24 alır. Artık Pi iki ağa sahip bir yönlendiricidir ve bağlı segmentin tam olarak bir çıkışı vardır.

Taahhüt vermeden önce aralığı diğer her şeye karşı denetleyin: tünelin kendi alt ağı, diğer siteler arası önekler ve VPN üzerinden erişilebilen her şey. Uzak bir LAN ile çakışan 10.20.0.0/24, teşhisi bir akşam süren yarı çalışan sonucu verir. İkinci port bir USB bağdaştırıcısıysa desteklendiğini doğrulayın ve yeniden başlatmadan sonraki yeniden sıralama LAN adresinizi kaydırmasın diye adını ağ yöneticisine sabitleyin.

DHCP dinleyicisini yalnızca o arayüzde çalıştırın. Yukarı bağlantıda yanıt veren bir sunucu ISP yönlendiricisiyle yarışır ve segmentinizin adreslerini evin geri kalanına dağıtır. Onu LAN arayüzüne bağlayın, bildirilen aralıkla sınırlayın ve Pi'nin kendi adresini havuzun dışında tutun.

İletme, çeviri ve arızada kapanma kuralı

Dört şey sık sık tek şey gibi anlatılır ve değildir. İletmeyi açmak (net.ipv4.ip_forward=1) çekirdeğe yalnızca paketleri arayüzler arasında taşıyabileceğini söyler; kendi başına hiçbir şeye izin vermez ve hiçbir yolu garanti etmez. Çıkışı seçmek bir yönlendirme kararıdır. Pakete izin vermek forward zincirinde bir politika kararıdır. Kaynağını yeniden yazmak bir postrouting kararıdır. Yalnızca ilkini yapan bir yapı, istemci trafiğini seve seve yukarı bağlantıdan dışarı ileten bir Pi üretir.

İzni amaçladığınız kaynaklarla ve trafiğin kullanması gereken arayüzle sınırlayın; dönüş yolunu ve Pi'nin ihtiyaç duyduğu hedefleri de ekleyin. Sonra sağlayıcı LAN önekinizi size geri yönlendirmiyorsa tünel çıkışında çeviri yapın. nftables kılavuzu iletmeyi, yerel çıkışı ve kaynak çevirisini ayrı işlemler olarak ele alır, burada doğru düşünce modeli budur.

Yaygın arıza, fiziksel arayüzde geniş bir masquerade kuralıdır. O zaman trafik ISP yolundan internete ulaşırken istemci tarafından tam olarak çalışan bir VPN gibi görünür. Bu hiçbir şeyi kanıtlamaz. Çeviriyi bildirilen çıkışa bağlı tutun ve kurallarınızı ana makinenin zaten kullandığı güvenlik duvarında tutun, paylaşılan bir postrouting zincirini boşaltan rakip bir kural kümesi eklemek yerine.

Sonra tünelin yokluğunu ele alın. Geniş bir varsayılan yol kuran istemci profili, tünel düştüğünde olağan varsayılanın geri dönebileceği ve istemci trafiğinin sessizce yukarı bağlantıya döndüğü anlamına da gelir. Nerede açık metne geri dönüş kabul edilemezse, forward politikası istemciden yukarı bağlantıya trafiği açıkça reddetmelidir, VPN yolunun gittiği durumda. Bunu bir varsayım olarak değil, ret kuralı olarak yazın. Pi'nin VPN eşine kendi şifreli taşıması ayrı bir local-output akışıdır ve izinli kalmalıdır, yoksa tünel asla geri dönemez.

DNS ve IPv6 kendi yanıtlarına ihtiyaç duyar

İstemciler Pi'yi çözümleyici olarak kullanırsa yerel bir dinleyiciye ulaşırlar ve Pi yeni bir sorgu başlatır. Bu yukarı akış sorgusu, istemciler için yazdığınız forward kuralını değil Pi'nin kendi yolunu izler, dolayısıyla yalnızca tünelden giden istemci yolu artı doğrudan çıkan bir çözümleyici, hiçbir hata iletisi olmayan bir sızıntıdır. Bilinçli olarak karar verin: tünel üzerinden erişilen bir çözümleyici mi, doğrudan kabul ettiğiniz yerel bir çözümleyici mi, ve Pi'nin kendi çıkış politikasını bu kararla uyumlu hale getirin.

IPv6 yine ayrı bir durumdur. IPv4 için forward kuralı IPv6 konusunda hiçbir şeyi sınırlamaz ve yukarı bağlantıdaki yönlendirici duyuruları Pi'ye ve onun üzerinden bağlı segmente politikanızı atlayan ikinci bir varsayılan verebilir. Ya aynı ilkeyle IPv6'ya kendi korumalı yolunu verin ya da istemci segmentinde açıkça sınırlayıp bunu söyleyin.

Güvenmeden önce sınırı test edin

Tasarımı ancak dört ayrı denetimden sonra kabul edin, çünkü baştan çıkarıcı tek test — bir istemcide tarayıcı açmak — birçok bozuk durumda geçer.

Gerçek bir istemcinin tünel üzerinden internete ulaştığını doğrulayın, sonra aynı istemcinin tünel kapalıyken internete ulaşamadığını doğrulayın. DNS çözümlemesinin çalıştığını ve sorgunun amaçladığınız yerden çıktığını doğrulayın. Tünel yeniden başlatıldıktan sonra Pi'nin kendi taşımasının hâlâ çalıştığını ve kurtarmanın makineyi yeniden başlatmayı gerektirmediğini doğrulayın. Son olarak seçmediğiniz bir cihazı denetleyin: düzen A'da normal çalışmaya devam etmelidir, düzen B'de ise o segmentte hiç bulunmamalıdır.

• İki port ve bir ret kuralı yaptırım sağlar; bir port ve bir DHCP seçeneği tavsiye sağlar.
• Yanlış arayüzde çeviri başarı gibi görünür ve değildir.
• Pi'nin kendi trafiği, DNS ve IPv6 her biri bir karar gerektirir, bir çıkarım değil.