Aynı sunucu IP'si, iki yol: OpenVPN'nin dış akışını işaretlemek

Olağan döngü koruması bir ana bilgisayar yoludur: VPN sunucusunun genel adresine giden trafiği uplink üzerinden dışarı gönderin ki şifreli oturum hiçbir zaman kendi tünelinize girmesin. Bu, aynı sunucudaki bir web hizmetine de tünel üzerinden ulaşmak isteyene kadar çalışır, çünkü muafiyet hedefe bağlıdır ve hedef aynıdır. Çıkış yolu, hedefe göre sınıflandırmayı bırakıp paketi hangi soketin gönderdiğine göre sınıflandırmaya başlamaktır.

Ayırmak istediğiniz iki akışla başlayın

Bir akış, uplink üzerinden çıkması gereken şifreli OpenVPN taşımasının kendisidir, aksi halde tünel kendi dış bağlantısını taşırdı. Diğeri, tünelin içinde istediğiniz, aynı genel adrese yapılan sıradan bir HTTPS isteğidir, böylece hizmete tünel kaynağından ulaşır. Aynı hedef, çoğu durumda aynı bağlantı noktası numarası, farklı gerekli yol.

Bu incelemede, 10.90.0.10 adresinde tun1 üzerinden bir istemci, 198.51.100.25 genel sunucu adresi ve varsayılan yolu olağan uplink'e işaret eden dokunulmamış bir ana tablo varsayalım. Sunucu tarafı ayrıca web hizmetini iç yolda kabul etmeli ve trafiği tünel kaynağına geri göndermelidir; bir paketi genel adrese göndermek sunucunun dinleyicisini veya güvenlik duvarı politikasını geçersiz kılmaz.

Herhangi bir şeyi değiştirmeden önce ana bilgisayarın mevcut kurallarını kaydedin ve kimsenin kullanmadığı değerler seçin: bir işaret, bir tablo numarası ve üç kural önceliği. Makineye bu bağlantı üzerinden gitmeyen bir dönüş yolu bırakın, çünkü buradaki bir hata yalnızca bir tarayıcı sekmesini bozmakla kalmaz, kendi uzak erişiminizi de ortadan kaldırır.

Zarfı taşıyan soketi işaretleyin

İstemci yapılandırması şifreli giden paketleri için bir işaret kazanır ve yolları kendi kurmayı bırakır, böylece yolları belirleyen tek şey yedek politikadır:

mark 42
route-noexec
disable-dco

Ondalık 42, onaltılık 0x2a'dır ve yönlendirme kurallarının eşleştireceği biçim onaltılık olandır. link-options başvurusu mark'ı Linux'ta şifreli giden paketlere uygulanan bir şey olarak tanımlar; bu da tam olarak yolunu denetlemeniz gereken sokettir. Veri kanalı boşaltmasını kapatmak bu örneği, işaret davranışının tanımlanan davranış olduğu kullanıcı alanı yolunda tutar.

route-noexec, OpenVPN'nin otomatik yol ekleme ve kaldırmasını bastırır. Onların yerine hiçbir şey kurmaz, bu yüzden bu andan itibaren yol sahibi tünelin ihtiyaç duyduğu her yolu sürdürmek zorundadır. Değişiklikten sonra özel bir hedef kaybolursa, bu eksik yedek politikadır, işaretteki bir kusur değil.

Bunu yaparken 198.51.100.25 için ana tabloda bir ana bilgisayar yolu tutmayın. Böyle bir yol, tasarımın daraltmaya çalıştığı muafiyeti tam olarak yeniden getirir ve aşağıdaki politikaların herhangi birine başvurulmadan önce HTTPS akışı için kazanır.

Geri kalan her şeyi tünel tablosuna gönderin

Tünel arayüzü var olup adresini tuttuğunda politika şöyle görünür:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

İlk kural, ana bilgisayarın belirli yollarını görünür tutar, onaylanmış herhangi bir yerel ağ dahil, ama ana tablonun varsayılan yolunu bu arama için görünmez yapar. Bu ayrım önemlidir: varsayılanı bastırmak, tabloyu yok saymakla aynı şey değildir ve hâlâ ihtiyaç duyduğunuz yerel istisnalar tam da bu sayede hayatta kalır. Bu istisnaları tek tek okuyun, sonucun evrensel bir acil durdurma anahtarı olduğunu varsaymak yerine.

İşaretsiz trafik sonra tünel tablosuna düşer, tünel kaynağını alır ve VPN üzerinden çıkar. İşaretli trafik sonraki iki kuraldaki fwmark testinde başarısız olur ve listenin daha aşağısındaki olağan ana aramaya devam eder, uplink varsayılanının hâlâ bulunduğu yer. Son unreachable kuralı, tünel yolu eksik olduğunda işaretsiz bir akışın sessizce uplink'e geri düşmesini engelleyen şeydir. Seçici baştan sona işarettir ve hedef adresi asla karara girmez.

Bu korumayı bağlantı kesintileri arasında yerinde tutun ve politikasının geri kalanıyla birlikte kurun, elle değil. Arayüzle birlikte kaybolan bir kural politika değil, tesadüftür. Tünel düştüğünde politikayı silmek arıza modunu “engellendi”den “sızdı”ya değiştirir ve sonradan süresi dolan eski bir tünel yolu, yanlış arayüzden çıkan trafikten çok daha kolay açıklanabilir bir sorundur.

Dönüş yolu aynı işareti görsün

Giden işaretler mekanizmanın yalnızca yarısıdır ve bu, çoğu yeniden üretimin atladığı kısımdır. Şifreli oturuma gelen yanıtlar uplink üzerinden gelir ve kaynağın geldiği yoldan geri yönlendirilip yönlendirilmeyeceğini soran dönüş yolu doğrulamasına tabidir. Yardım olmadan bu arama sizin işaretsiz tünel politikanızı uygular ve paketin yanlış arayüzde olduğu sonucuna varır.

Düzeltme güvenlik duvarı sahibine aittir: işareti giden bağlantıya kaydedin, eşleşen gelen paketlere geri yükleyin ve ilgili yol için kaynak doğrulamalı işaret işlemeyi etkinleştirin. OpenVPN'nin bir soket işareti ayarlaması bu üç şeyin hiçbirini yapmaz ve yalnızca istemci seçeneklerini listeleyen bir tarif eksiktir. Bu entegrasyonu yazılı olarak isteyin, çünkü tasarımın en az görünen parçasıdır ve yeniden kurulumda kaybedilmesi en kolay olanıdır.

Gevşek dönüş yolu denetimi de bir yedek değildir. Gevşek mod yine de kaynak için bir yolun var olmasını gerektirir ve eklediğiniz unreachable koruması işaretsiz aramalar için bilerek bir tanesini kaldırır. Bu tasarıma güvenmeden önce bağlantı işareti entegrasyonunu tamamlayıp gözden geçirtin ve ana bilgisayar filtrelerini ayrı bir soru olarak ele alın: işaret bir yönlendirme sinyalidir, izin değil. Entegrasyon eksikse belirti, kurulan ve yanıtlar gelmeye başlar başlamaz sessizleşen bir oturumdur.

İki yol aramasıyla kanıtlayın

Çekirdeğin iki bağlam için ne karar verdiğini karşılaştırın ve çıkış durumu yerine dev ve src alanlarını okuyun:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

İlk arama tünel kaynağıyla tun1'e, ikincisi uplink'e çözülmelidir. Bunlar sentetik aramalardır, bu yüzden politikayı kanıtlarlar, çalışan süreci değil: çalışan istemcinin gerçek taşıma yolunu ayrıca doğrulayın, sonra sertifika doğrulaması açıkken gerçek bir HTTPS isteği yapın.

Tamamlandı ilan etmeden önce tasarımın neleri kapsamadığını yazın. DNS, IPv6 ve kuralların yaşam döngüsü her biri kendi kararını gerektirir ve bu bir IPv4 yönlendirme örneğidir, eksiksiz bir gizlilik yapılandırması değil. Değeri seçicidedir: zarf uplink muafiyetini alır ve aynı adresteki sıradan bir hizmetin bunu miras alması gerekmez.