Ayrı çıkış: usb0 üzerinde VPN havuzu, eth0 üzerinde ağ geçidi trafiği
İletilen VPN istemcileri usb0 üzerinden çıkabilirken ağ geçidi kendi eth0 varsayılan yolunu korur. Eksiksiz bir seçili tablo oluşturun, sonra arızayı sızıntı yerine kapanma yapacak hale getirin.
İstemciler bağlanıp kimlik doğrular, ardından trafikleri yanlış üst bağlantıdan çıkar, çünkü makinedeki tek varsayılan yol ağ geçidinin kendisine aittir. Bu varsayılan yolu değiştirmek makinenin kendi güncellemelerini ve yönetim erişimini bozar, bu yüzden seçim «tüm trafik»ten daha dar olmalıdır. Çalışabilir biçim, istemci havuzunun iç kaynak adresine dayanan ve alternatif WAN'a sahip ikinci yönlendirme tablosunu gösteren bir politika kuralıdır. Oradan sonra kontrol listesi kuralın kendisiyle değil, bütünlük ve arıza anındaki davranışla ilgilidir.
Kaynak adresin yönlendirme kararına kadar yaşadığını doğrulayın
Kaynak aralığıyla eşleşen bir politika kuralı yalnızca paket arama anında hâlâ o kaynağı taşıyorsa devreye girer. İletilen istemci trafiği, yönlendirmeden önce yukarıda hiçbir şey onu yeniden yazmadığı sürece bunu yapar. Ağ geçidinin kendi ürettiği trafik bunu yapmaz ve tam da bu nedenle ağ geçidinin kendi varsayılan yolu yerinde kalabilir.
Yerel testler tam burada yanıltır. Ağ geçidinde çalıştırılan curl, ağ geçidinin adresiyle yerel olarak üretilmiş bir akıştır, bu yüzden ana tabloyu alır ve istemci yoluna dair hiçbir şey kanıtlamaz. Bağlı bir istemciden test edin veya kaynağı gerçekten havuza ait olan trafik üretin.
Gerçek değerleri yazarak başlayın: havuz öneki, onu taşıyan tünel arayüzü, ikinci WAN'ın adresi ve sonraki atlaması ve kullanmayı düşündüğünüz tablo numarası. Yeni kurallar eklemeden önce önceki her denemenin eski kurallarını temizleyin, çünkü farklı önceliklerdeki yinelenen kurallar rastgele görünen arızalar üretir.
Eksiksiz bir seçili tablo oluşturun
Tablo, arkadaşı olan bir varsayılan yol değildir. Her aramanın kendi içinde çözülmesi için yeterli yol gerekir; sonraki atlamanın erişilebilir olması için WAN alt ağının bağlı yolu da dahil. tun1 üzerinde 10.77.0.0/24 havuzu, sonraki atlaması 203.0.113.1 olan 203.0.113.20/24 WAN adresi ve 600 tablosu için:
ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600
Kural, mevcut her şeyi yakalayan herhangi bir kuralın altında bir öncelikte durur, bu yüzden eşleşen istemciler önce 600 tablosuna çarpar ve geri kalan her şey ana tabloya düşer. ip-rule başvurusu sıralı arama modelini ve seçici sözdizimini tam olarak açıklar.
Sonra tablonun neyi içermediğini düşünün. Yalnızca ana tabloda yolu olan bir hedef, örneğin eth0 üzerinden erişilebilen bir yönetim alt ağı, 600 tablosunda bulunmaz ve orada varsayılan bir yol olduğunda ana tabloya geri düşmez. Bu yollar önemliyse bunları seçili tabloya açıkça ekleyin; VPN çıkış tablosu için genellikle doğru yanıt budur.
Dinleyicinin kendi trafiğini politikanın dışında tutun
OpenVPN dinleyicisinin kendi dış bağlantısı vardır ve istemcinin ona ulaştığı üst bağlantı üzerinden taşınır. Bu trafik geldiği dönüş yolunu korumalıdır; sunucunun genel adresini veya tüm tünel arayüzünü kapsayan geniş bir kural onu alternatif tabloya çekebilir. Kuralı iç havuzla sınırlayın, başka hiçbir şeyle değil.
Ters yol süzgeci de aynı nedenle göz atmaya değer. İstemcilere yanıtlar usb0 üzerinden çıkarken istek başka bir bağlantıdan geldiyse, katı bir rp_filter ayarı yönlendirme politikasının geçerli saydığı paketleri düşürebilir. Kuralın başarısız olduğu sonucuna varmadan önce iki arayüzdeki geçerli sysctl değerlerini denetleyin.
Sıra, makinedeki diğer her şeye göre de önemlidir. Docker köprüleri, ikinci bir VPN ve sağlayıcı imajından önceden var olan kurallar öncelik ekler, bu yüzden 100 önceliğinin tek başına olduğunu varsaymak yerine tüm kural listesini okuyun.
İletmeyi ve çeviriyi yolla uyumlu hale getirin
Yönlendirme bir üst bağlantı seçer; iletmeye izin vermez. Çekirdekte IPv4 iletimi etkin olmalı ve güvenlik duvarı istemciden WAN'a yönü ve dönüş trafiğini kabul etmelidir. Akışı düşüren bir FORWARD zinciriyle doğru tablo, eksik yolla aynı belirtiyi verir, bu yüzden ikisi aynı geçişte denetlenir.
İkinci WAN özel bir havuzu size geri yönlendirmeyecekse çıkışta kaynağı çevirin. Dinamik adresli bir arayüz için olağan seçim, havuz ve arayüzle sınırlı dar bir masquerade kuralıdır:
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE
Burada kapsam hedeften daha önemlidir. Herhangi bir giden arayüzle eşleşen masquerade kuralı, eth0 üzerinden doğru çıkan trafiği de yeniden yazar ve bu, yönlendirme hatalarını düzeltmek yerine gizler. Çeviri yönlendirme kararından sonra çalışır, bu yüzden yanlış üst bağlantıya gönderilen paketi asla onaramaz.
Yollar farklılaştığında tünel yükü de dikkat ister. İstemciler büyük bir TCP MSS üzerinde anlaşırsa ve alternatif WAN'ın MTU'su daha düşükse veya içinde tünel varsa, büyük segmentler tıkanır küçükler çalışır. İletim yolunda MSS'yi sıkıştırmak bunu ara sıra takılma yerine öngörülebilir bir davranışa çevirir.
usb0 kaybolduğunda ne olacağına karar verin
Boş tablo arıza anında kapanan bir durum değildir. Eşleşen yol kaybolursa arama sonraki kurala geçer, ana tabloya ulaşır ve eth0 varsayılanını alır. İkinci WAN'dan çıkması gereken trafik sessizce birinciden çıkar; politika yönlendirmeli bir kurulumda bu genellikle en az istediğiniz sonuçtur.
Bu geri düşüşün kabul edilemez olduğu yerlerde 600 tablosuna açık bir terminal yol ekleyin, örneğin blackhole varsayılanı, ya da arayüz kapalıyken havuzu güvenlik duvarında düşürün. İkisinden biri yazabileceğiniz bir karardır; sessizlik değil.
Kalıcılık son maddedir. İki bağlantıya da sahip olan kim olursa olsun, ister ağ yöneticisi, ister gönderici betiği, ister bağlantının yaşam döngüsü olsun, her yeniden bağlanmada yineler eklemeden yolları ve kuralı yeniden oluşturmalıdır. Gerçek bir istemciden gelen istekle ve ağ geçidinden ayrı bir istekle doğrulayın, gözlenen çıkışı ikisinde de onaylayın, sonra ikinci WAN'ı çekin ve tasarladığınız iki sonuçtan hangisinin gerçekten gerçekleştiğini görün. IPv6 kendi tablosuna, kuralına ve çevirisine ihtiyaç duyar; yukarıdaki IPv4 kuralı bunun hakkında hiçbir şey söylemez.