Bir Linux hesabını UID kuralıyla OpenVPN üzerinden yönlendirme
Bir uidrange kuralı, bir hesabın IPv4 soketlerini namespace olmadan mevcut bir tünele yerleştirir. DNS, IPv6 ve yedek yolu ayrı ayrı kararlaştırın, sonra doğrulayın.
Hesap tabanlı yönlendirme, tek bir Linux kullanıcısına ait her IPv4 soketinin mevcut bir tünelden çıkması gerektiğinde uygundur ve program düzeyinde yalıtım gerektiğinde uygun değildir. UID'ye göre seçer, bu yüzden o hesapla çalışan her şey kapsam içindedir, unuttuğunuz toplu iş dahil. Tek bir ip rule dokunmadan önce bu soruyu netleştirin.
Aşağıdaki örnek, UID 1500'de ayrılmış bir tarayıcı hesabı, 10.80.0.11 yerel adresini taşıyan tun-office tünel aygıtı ve söz konusu hedeflere izin veren bir VPN varsayar. Daemon'ın kendisi bu UID'nin dışında çalışır.
Mekanizmayı seçen üç koşul
UID kuralını, işi yapan kimlik hesap olduğunda, tüm trafiğini taşımak kabul edilebilir olduğunda ve namespace görevin hak ettiğinden ağır olacaksa seçin. Ağ namespace'ini, iş yükü kendi arayüzlerine, çözümleyicisine ve yönlendirme tablosuna ihtiyaç duyduğunda seçin. Proxy'yi veya süreç başına bağlamayı, tam olarak bir uygulamanın taşınması gerektiğinde seçin; oturumun geri kalanı yerel yolda kalır. Bu üçünü yazmak, amaçlanandan fazlasını sessizce kapsayan bir kuralı önler.
Kaçınılması gereken hata, başlatıcının sahibi belirlediğini varsaymaktır. Başka bir kullanıcının oturumundan URL alan bir tarayıcı UID 1500 altında soket oluşturmamıştır ve hiçbir kural onun ürettiği trafiği taşımaz.
Tablo, kural ve koruyucu
Mevcut kuralları denetleyip kullanılmayan tablo ve öncelik numaralarını seçtikten sonra düzen kısadır: tünelin kaynak adresini taşıyan ayrılmış tabloda varsayılan yol, hesabın aramalarını o tabloya gönderen kural ve yedek yolu kapatan sonlandırıcı kural. Yazıya döküldüğünde bu, etkisiz yinelenebilir bir yol değişimidir, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, ardından ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820 gelir.
Koruyucu ip -4 rule add priority 12101 uidrange 1500-1500 unreachable ve uzunluğunun ima ettiğinden daha önemli. O olmadan, tablo 51820'deki eksik yol olağan üst bağlantıya düşer ve hesap, ilkenin yakalaması gereken trafiği sessizce sızdırır. Onunla aynı arıza bir zaman aşımına, yani yedek yerine engellemeye dönüşür.
Olağan yerel adres kuralını bunların önünde tutun ve LAN veya yönetim istisnalarının seçilen tablodan önce gelip gelmeyeceğine bilinçli olarak karar verin. Orada bulunan varsayılan yol, daha sonra daha belirgin bir LAN yolu için main sormaz; bu, en uzun önek eşleşmesinin tablolar arasında geçerli olduğunu bekleyenleri şaşırtır. Amaçlanan istisna listesini, gerekçe hâlâ tazeyken değişiklik notuna yazın.
UID yönlendirmesinin dışarıda bıraktığı: DNS
Çözümleyici daemon, üst akış soketlerini kendi UID'si altında açar, bu yüzden 1500'ü seçmek bu sorguları tablo 51820'ye taşımaz. DNS entegrasyonu ayrı bir karardır: hesabı tünelden erişilebilen bir çözümleyiciye yönlendirin veya ad çözümlemenin ana makinenin yolunu izlediğini, trafiğin izlemediğini kabul edin.
Yerel bir stub'a loopback sorgusu, üst akış sorgusunun tarayıcının yolunu kullandığının kanıtı değildir; önbellekten başarılı bir sayfa yüklemesi de değildir.
IPv6 tasarımda kendi cümlesini gerektirir
Yukarıdaki kurallar yalnızca IPv4'ü kapsar. Gereksinim bu hesaptan doğrudan IPv6 olmayan bir IPv4 tüneliyse, ip -6 rule add priority 12101 uidrange 1500-1500 unreachable gibi gözden geçirilmiş bir sonlandırıcı kural ekleyin, sonra önceki IPv6 kurallarını ve tutmak istediğiniz loopback istisnalarını denetleyin.
Doğrudan IPv6'yı engellemek çift yığın tünelleme değildir; bu bir sınırdır. Buna tünelleme demek, ilkeyi okuyacak bir sonraki kişiyi şaşırtacak ve karışıklık, bozuk bir IPv6 sitesi hakkında bir destek kaydı olarak ortaya çıkacaktır.
Gerçek hesapla doğrulayın, sonra yaşam döngüsünü üstlenin
Aramaları karşılaştırın: aynı hedefe normal UID ile ip -4 route get 198.51.100.25 uid 1500. Sonra ayrılmış hesap altında izin verilen bir istek yapın ve uzak ucun gördüğü kaynak adresi denetleyin. Tercih edilen kaynak adres source NAT değildir ve başka bir şeyi bağlayan bir uygulamayı geçersiz kılmaz. İki arama da aynı yolu döndürüyorsa kural sandığınız şeyi yapmıyor.
Tabloyu, kuralları ve tünel yolunun ömrünü tek bir sahip altında tutun, yeniden bağlanmayı ve tünel kaybını test edin, ilke kaldırılırken yalnızca tam girdilerini silin. Ayrı arayüzler ve ayrı durum gerçekten ihtiyacınız olan şeyse namespace hâlâ kullanılabilir.