Çok yönlendiricili Pi VPN: her yolu karar veren cihaza koyun
Aşağı akıştaki yönlendirici ikinci bir istemci alt ağı ekler ve dört cihazın her biri bir karara sahiptir. Yolları yerleştirin, kaynağı kontrol edin, sonra gerçek bir istemciden test edin.
Pi'nin arkasına bir Wi-Fi kutusu koymak bir yönlendirme kararını dörde çıkarır ve dördü de tek bir cihazda verildiğinde plan bozulur. İlk soru hangi yolun ekleneceği değildir. Yeni kutunun köprü mü kurduğu yoksa yönlendirme mi yaptığıdır, çünkü bu yanıt kaç alt ağ olduğunu ve hangi cihazların bunları öğrenmesi gerektiğini belirler. Önce bağlantı modelini seçin; her yol ondan gelir.
Köprü mü yönlendirme mi: sayıyı belirleyen seçim
Bir köprü yeni istemcileri Pi'nin zaten hizmet verdiği aynı alt ağa koyar. Tek alt ağ, tek DHCP yetkisi ve yönlendirmeye devredilecek bir şey yok. Bu daha basit düzenlemedir ve ayrı bir istemci ağı hiçbir zaman gereksinim olmadığında doğru seçimdir. Yönlendirilmiş bağlantı farklı bir tasarımdır: kutu kendi alt ağını korur ve bu önek trafiğin gittiği her yere taşınmalıdır.
Planın geri kalanı aşağı akıştaki yönlendiriciyi korur ve istemcilerin kaynak adreslerini saklar. Hedef tam bir internet çıkışı değil, tek bir özel VPN ağıdır. Modeli adreslerden önce yazın, çünkü aşağıdaki liste yalnızca yönlendirilmiş bir bağlantı örneğidir.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24Kim neye karar verir
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Her cihaz bir karar verir ve hiçbiri bir diğerininkini onun yerine veremez. Pi'nin iki girdiye ihtiyacı vardır, bir değil, ve insanların unuttuğu şey dönüş yoludur. İletilen trafik özel ağa doğru şekilde ulaşır ve sonra dönüş yolunda ölür, çünkü Pi 10.41.0.0/24'ün nerede yaşadığı hakkında hiçbir fikre sahip değildir. Bu bir güvenlik duvarı sorunu gibi görünür ve aslında eksik bir yoldur.
Uzak tarafın da kendi yoluna ihtiyacı vardır. Uzak uçtaki hizmet 10.41.0.0/24'e tüneliniz üzerinden ulaşılabildiğini bilmiyorsa, yanıtlar yanıtı olmayan ilk sıçramada durur. Paket filtrelerini okumadan önce iki yönü de ekleyin.
Sonraki sıçramalar bağlantıdan gelir
Sonraki sıçrama, cihazın gerçekten ulaşabildiği bir ağdaki adres olmalıdır. VPN eşinin genel adresi özel bir alt ağ için sonraki sıçrama değildir ve uzaktaki hizmet ağı hiçbir şekilde sonraki sıçrama değildir. Ulaşılamayan bir ağ geçidine giden yol bir listede doğru görünür ve her paketi düşürür. Hedefi suçlamadan önce ağ geçidinin yanıt verdiğini kontrol edin.
Pi'nin dış VPN eşini kendi alt katman yolu üzerinden ulaşılabilir tutun. Bu girdi yük yollarından ayrıdır ve bunları karıştırmak, yol değişikliğinden sonra yeniden kurulamayan bir tünel verir.
Statik yollar belgeleri her platform menülerini farklı adlandırsa da hedef ile ağ geçidi arasındaki farkı açık hale getirir. Başka bir satıcının ekranını kopyalamak yerine önünüzdeki cihazın belgelerini okuyun. Aşağıdaki komutlar girdilerin Linux'taki biçimini gösterir.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1Çevirinin kaynağa yaptığı şey
Aşağı akıştaki yönlendirici istemcilerini zaten geçiş adresine çeviriyorsa, Pi her istemcinin kendi adresi yerine tek bir çevrilmiş kaynak görür. Bu, yukarıdaki kaynağı koruyan tasarımdan farklıdır. Kaynak tabanlı politikayı, günlük kaydını ve hangi tarafın bağlantı başlatabileceğini değiştirir. İki tasarım da çalışır; farklı soruları yanıtlarlar.
Yukarı akıştaki bir VPN hizmeti istemci önekini geri yönlendirmeyi reddettiğinde, Pi'nin tünel çıkışındaki dar bir çeviri meşru bir geçici çözüm olabilir. Bu, eksik yolun gereksiz olduğunun kanıtı değildir. Uzak ağın gerçekte hangi adresi gördüğünü ve hangi dönüş yolunun oluştuğunu kaydedin.
Yol seçimi, iletme izni ve kaynak çevirisi üç ayrı iş olarak kalır. Bir kablolu istemci çalıştığı için paylaşılan bir NAT zincirini boşaltmak veya her arayüze izin vermek, çalışan bir testi açık bir ileticiye dönüştürmenin yoludur.
Bunu bir istemci makinesinden kanıtlayın
Aşağı akıştaki LAN'daki bir makineden istek gönderin, sonra kaynağını dışarı ve geri takip edin. Pi'nin gönderdiği ping aşağı akış dönüş yolunu asla kullanmaz, bu yüzden başarılı bir ping göründüğünden daha azını kanıtlar. Pi'nin kendi LAN'ındaki kablolu bir istemciden ikinci bir test ekleyin, böylece iki yol karşılaştırılabilir. Herhangi bir cihazı yeniden başlattıktan sonra ikisini de tekrarlayın.
Elle eklenen yollar ve hiç kaydedilmemiş çeviriler birlikte kaybolur. Sonra çift, bitmemiş bir iş değil yeni bir arıza gibi görünür.
Bağlantı modelini yollar, izin verilen özel hizmet ve herhangi bir çeviriyle birlikte tek bir notta saklayın. Bir sonraki kişiyi kablosuz yerleşimi bir yönlendirme politikası sorunu olarak görmekten alıkoyan şey o nottur.