Genel Linux hizmetiniz neden VPN üzerinden yanıtlıyor

Sokette hiçbir şey isteği hangi arabirimin taşıdığını hatırlamaz, bu yüzden tam tünelli bir VPN varsayılan rotası WAN'a ait bir yanıtı yakalayabilir. Hizmet gelen arabirimi yok saymıyor; Linux yerel olarak üretilen yanıtı hedefe ve kaynak politikasına göre yönlendirir. Kaynak tabanlı bir kural bunun yerine yalnızca hizmetin yanıtlarını tam bir WAN tablosu üzerinden gönderebilir ve olağan çıkışı tünelde bırakabilir. Yanıt yanlış yoldan çıkarken bağlantı noktası açık kalır, bu yüzden belirti tek taraflı görünür.

Yanlış kanı: yanıtlar geldikleri arabirimi izler

eth0'a gelen bir paketin eth0'dan çıkması mantıklı görünür. Durumsuz paket filtreleri böyle yazılabilir ve giriş tarafındaki tcpdump isteği tam beklenen yerde gösterir. Yönlendirme, ana makinenin kendi oluşturduğu trafikte böyle çalışmaz.

Hizmet bağlantıyı kabul ettiğinde yanıtı yeni, yerel olarak üretilmiş bir pakettir. Çekirdek yanıtın hedefi ve kaynağı için yönlendirme kurallarına bakar ve VPN'in varsayılan rotası tamamen geçerli bir yanıttır. Sokette hiçbir şey isteği hangi arabirimin taşıdığını hatırlamaz.

Bu yüzden belirti tek taraflı görünür: istekler gelir, yanıtlar kaybolur. Bu yüzden giriş bağlantı noktası için bir güvenlik duvarı kuralı eklemek de hiçbir şeyi değiştirmez. Paket içeri giderken engellenmiyor; dışarı çıkarken başka bir yere yönlendiriliyor. Yanıtı kaynakla nitelenmiş bir aramayla izleyin, dolambaç görünür hale gelir.

Çekirdeğin gerçekte yönlendirdiği şey: kaynak adresi

İhtiyacınız olan tutamak, hizmetin yanıtlar için kullandığı yerel adrestir. eth0 adresi örnek olarak 192.0.2.10/24 ve ağ geçidi 192.0.2.1 olan bir ana makinede bu adres arabirimde bulunur. Bir bulut VM'inde genel adres yukarıda çevrilmiş ve konukta bulunmuyor olabilir, bu yüzden ana makinenin gerçekten sahip olduğu adresi kullanın.

Bir tablo numarası veya kural önceliği ayırmadan önce mevcut durumu inceleyin. Var olan ilke kuralları yenisini gölgeleyebilir ve aynı numaralı eski bir tablo zaten ilgisiz rotalar taşıyor olabilir:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Ardından kaynağa göre bir tablo seçin. Kural, zaten 192.0.2.10 taşıyan yanıtlarla eşleşir; bu tam olarak muaf tutmak istediğiniz yerel sonlanan trafiktir. İletilen trafik ve diğer yerel adreslerden gelen paketler eşleşmez.

Yarım varsayılan değil, tam bir dönüş tablosu kurun

Yalnızca varsayılan rotası olan bir tablo yeterli değildir. Çekirdeğin yine de ağ geçidini çözmesi gerekir ve bu çözüm aynı tabloda bağlı öneki gerektirir. Bu öneki eksik olan bir tablo, varsayılan rotası doğru görünse bile ağ geçidi çözümünde başarısız olur. İkisini de ekleyin, sonra kaynak kuralını tabloya yönlendirin:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Örneği kopyalamak yerine gerçek öneki ve ağ geçidini kullanın. On-link ağ geçidiyle /32 olarak yapılandırılmış bir bulut arabirimi farklı bir bağlı rota gerektirir ve yanlış önekten kurulan bir tablo ilk sıçramada başarısız olur. src özniteliği o rota için tercih edilen kaynağı belirtir; kaynak kuralının yerini almaz.

Sıra da önemlidir. Daha düşük öncelik numarasına sahip geniş bir kural önce değerlendirilir, bu yüzden kaynak kuralına bu trafiği ana tabloya geri gönderecek herhangi bir kuraldan önce ulaşılmalıdır. Ekledikten sonra öncelikleri ip rule show ile kontrol edin, yalnızca açılışta değil.

Kaynakla nitelenmiş bir aramayla doğrulayın

Çekirdekten hizmet adresinden bir test hedefine yönlendirme yapmasını isteyin. Yanıt tüneli değil, eth0 ve WAN ağ geçidini adlandırmalıdır:

ip -4 route get 198.51.100.25 from 192.0.2.10

Ardından yeni bir yetkili bağlantı kurun ve iki yönü de gözlemleyin. Doğru tabloyu seçen bir arama, canlı bağlantı hâlâ başarısızken tabloya değil, ters yol filtrelemesine veya bir güvenlik duvarı kuralına işaret eder. Bir şeyi genel olarak devre dışı bırakmadan önce bu denetimleri kontrol edin.

Son rotaları ve kuralı arabirimin sahibi olan ağ yöneticisinin altına yerleştirin. Adres değişiklikleri, DHCP yenilemesi ve VPN yeniden bağlanmaları çekirdek durumunu yeniden yazar ve elle eklenen bir kural sonraki olaydan sonra kaybolur veya eski bir ağ geçidine işaret eder.

Bu istisnanın bittiği yer

Kural, tek bir kaynak adresinden yerel sonlanan trafiği muaf tutar. Docker'ın yayımladığı bağlantı noktalarını, DNAT'ı veya ana makine üzerinden iletilen hizmetleri kapsamaz, çünkü bu paketler iletilen trafik olarak yönlendirilir ve ana makinenin yerel kaynağını asla aynı şekilde taşımaz. Bu tür tasarımlar genellikle girişte ayarlanan bir işaret ve o işaretle eşleşen bir kural gerektirir.

Ana makinenin genel adresinin arabirimde görünmesini de sağlamaz. Üst akıştaki bir NAT o adrese sahip olduğunda, yanıt yine de o NAT'ın beklediği yoldan çıkmalıdır, bu yüzden WAN tablosu tahmin edilen bir genel aralık yerine özgün ağ geçidini ve öneki yansıtmalıdır.

İstisnayı tablo numarası, kural önceliği ve tam kaynak adresiyle birlikte belgelenmiş tutun. VPN veya arabirimdeki sonraki değişiklik onu sessizce bozabilir ve üç değeri adlandıran bir not, belirtiyi bir müşteri raporundan yeniden keşfetmekten daha hızlı kontrol edilir.

Kaynakla nitelenmiş arama başarılı olduktan sonra hizmet hâlâ yanlış yoldan yanıt veriyorsa, canlı soketin kaynak adresini kuraldakiyle karşılaştırın. Joker karakterli bir adrese bağlı hizmet, test ettiğiniz adresten farklı bir kaynak seçebilir ve bu uyuşmazlık kalan boşluktur.