NAT arkasındaki bir OpenVPN istemcisi nasıl internet çıkışı olur

Üç Linux makinesi, tek tasarım: herkese açık bir OpenVPN merkezi, bir tüketici dizüstü bilgisayarı ve içeri hiçbir şey iletmeyen sıradan bir ev yönlendiricisinin arkasındaki bir çıkış makinesi. Çıkış, merkezi kendisi arar. Ardından tüketicinin internet trafiği dizüstünde tünele girer ve çıkışın kendi yukarı bağlantısından çıkar. Bu düzenlemedeki şaşırtıcı her şey tek bir ayrıntıdan kaynaklanır: bağlantıyı çıkış başlattı, dolayısıyla içeri giden yol zaten vardır ve onu oluşturmak için port yönlendirmeye gerek yoktur.

Aşağıdakiler yapılandırma sırasını değil paketin yolunu izler, çünkü yapılandırma ancak hangi bileşenin hangi kararı verdiğini bildiğinizde anlam kazanır. Her katman tam olarak bir karar verir ve hatalar iki katmanın bir sayıldığı yerde birikir.

İki taşıma oturumu, tek iç yol

Her makine merkeze kendi dış bağlantısını tutar ve bu bağlantıların hiçbiri diğerini bilmez. Tüketicinin internete giden trafiği ayrı bir iç akıştır; tüketicinin tüneli içinde taşınır ve sonra çıkışın tünelinden yeniden yayılır. Merkezin yönlendirmesi gereken bu iç akıştır ve çıkışın iletmesi gereken de odur.

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

İki dış bağlantı da istemci tarafından dışarı çıktığı için çıkışın yönlendiricisi hiçbir zaman gelen bir SYN görmez ve hiçbir zaman hedef NAT kuralına ihtiyaç duymaz. Yalnızca kurulmuş taşımayı canlı tutması gerekir, bunu her uzun ömürlü bağlantı için zaten yapar. Genel internette hiçbir şeyin önce çıkışa ulaşması gerekmez, bu yüzden o yukarı bağlantıdaki dinamik adres sorun değildir. Yönlendirici yine de giden oturuma izin vermelidir, ama bu bir tarayıcının zaten kullandığı iznin aynısıdır.

iroute sunucunun içine gerçekte ne kurar

Hangi eşin hangi hedefe sahip olduğuna karar veren tek aygıt merkezdir ve bu kararı çekirdeğin değil kendi kullanıcı alanı yönlendirme tablosunda verir. Çıkış için exit-node adlı client-config-dir girdisi orada varsayılan öneki talep edebilir:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

O satır sunucu sürecine "herhangi bir hedefi olan iç paketler bu istemciye aittir" der. Merkezin işletim sistemine varsayılan bir yol eklemez ve merkezi internet ağ geçidi yapmaz. OpenVPN 2.6 başvurusu istemciye özgü iç yönlendirme ile çekirdek yönlendirmesini ayrı mekanizmalar olarak tutar ve bu ayrım, tasarımın merkezin varsayılan yoluna dokunmadan çalışmasının nedenidir.

Tüketicinin ayna talimata ihtiyacı vardır, push olarak teslim edilir, böylece kendi trafiği yerel ağ geçidinden çıkmak yerine tünele girer. Alt ağ topolojisinde havuz, çıkışın tun aygıtında bağlı bir yoldur, bu yüzden dönüş yönü ek push gerektirmez; çıkışın almaması gereken şey aşağıdaki yönlendirmedir, o kendi yukarı bağlantı trafiğini kullanmaya çalıştığı tünele geri gönderir. Onu yalnızca tüketiciye gönderin ve CCD dosyasının seçildiğine inanmak yerine istemcide uygulanan yolları okuyun.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

İletmeyi çıkışın çekirdeği yapar

Çıkışın içinde tüketiciden gelen bir paket tun arayüzüne bir internet makinesi adresine gelir. Çekirdek yönlendirme tablosuna bakar, en iyi eşleşme olarak gerçek yukarı bağlantıyı bulur ve sonra iki bağımsız ilke uygular: bu paket hiç iletilebilir mi ve o kaynak adresle o arayüzden çıkabilir mi. İletme bir sysctl'dir ve birçok dağıtımda varsayılan olarak kapalıdır.

Yani çıkışın sürekli açık IPv4 iletmesine, tüketicinin tünel kaynaklarını yukarı bağlantıya kabul eden bir kurala ve tun üzerinden dönen yanıt yoluna ihtiyacı vardır. İletmeyi tüm makine için açmak, onun üzerinden yönlendirilen her şeyin davranışını da değiştirir, bu yüzden kural her şeyi kabul etmek yerine kaynakları ve arayüzleri adlandırmalıdır.

Dönüş yolunu kaynak çevirisi satın alır

Bir internet makinesinin 10.90.0.x adresine yolu yoktur, bu yüzden yanıtlar çıkışa ulaşmadan önce atılırdı. Paket yukarı bağlantıdan çıkarken kaynağı yeniden yazmak bunu çözer ve bağlantı izleme dönüşte bu yazımı geri alır.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

Yukarıdaki kural tek bir yukarı bağlantı arayüzü için başlangıç noktasıdır, güvenlik duvarı ilkesi değildir. Kaynağı gerçekten yetkilendirdiğiniz atamalara daraltın ve çıkışın kendi giriş ilkesini ayrı tutun, böylece tünel trafiği için maskeleme yerel hizmetleri sessizce açığa çıkarmaz. Yukarı bağlantı adresi dinamik olan bir makinede maskeleme sizi adresi elle izlemekten de kurtarır.

Merkez nerede uygulayabilir, nerede uygulayamaz

client-to-client ve geleneksel kullanıcı alanı veri yoluyla merkez, iç paketleri sunucu süreci içinde eşler arasında devreder. Bunlar hiçbir zaman merkezin çekirdek FORWARD zincirinden geçmez, bu yüzden oradaki bir çekirdek kuralı eşler arası geçişi ne kadar dikkatle yazılırsa yazılsın kısıtlayamaz. Uygulama sunucunun kendi ilkesinde yaşamalıdır: kimin bağlanabileceği, hangi CCD dosyasını alacağı ve çıkışın varsayılan sahipliğinin verilip verilmeyeceği.

Bu yüzden varsayılan iroute geniş bir güven kararıdır. Çıkış, rastgele internet adreslerinden gelen dönüş trafiğini meşru olarak kabul etmeli ve sizin denetlediğiniz, yamaladığınız ve izlediğiniz bir makine olmalıdır. Aynı sahipliği yönlendirici vermeyeceğiniz bir eşe vermek bu tasarımın davet ettiği hatadır.

Asıl denetim üyeliktir. Kendi yollarını yapılandırabilen her istemci çıkışı kullanmayı deneyebilir, bu yüzden kimin bağlanabileceğini veya çıkışın hangi eşlere hizmet edeceğini kısıtlamak tasarımın parçasıdır, sonradan akla gelen bir düşünce değildir.

Çıkış kaybolduğunda güvenli biçimde başarısız olmak

Çıkışı çevrimdışı yapın, iç varsayılan sahiplik oturumuyla birlikte kaybolur. Olmaması gereken şey merkezin sessizce yedek çıkışa dönüşmesidir: VPN havuzundan merkezin yukarı bağlantısına varsayılan bir yol yok ve merkezde aynı trafiği memnuniyetle iletecek geniş bir maskeleme kuralı yok. Bu başarısızlığı bilerek test edin, sonra kurtarmayı zaten açık olan bir sayfa yerine yeni bir akışla test edin.

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Çıkış gittikten sonra tüketicinin trafiği hâlâ internete ulaşıyorsa onu başka bir şey taşıyor ve amaçladığınız sınır yok. DNS ve IPv6'yı da ayrı kararlar olarak ele alın: IPv4 yolu artı maskeleme AAAA trafiği hakkında hiçbir şey söylemez ve merkezin ittiği çözümleyici sorgunun gerçekte çıktığı yerden yanıt verir.