VPN adresine bağlanan uygulama yine de yanlış rotayı kullanıyor

Bir uygulama VPN’in adresine bağlanır ve bağlantı yine de olağan varsayılan rotadan çıkar. Bağlamada hiçbir şey başarısız olmadı; bağlama tam olarak ne yapıyorsa onu yaptı. Bir soketi yerel adrese bağlamak, çekirdeğin başlığa koyduğu kaynak adresini seçer. Bir rota kurmaz ve bu kaynağı taşıyan paketleri belirli bir tünele gönderen bir ilke kuralı oluşturmaz.

Bu kılavuzun geri kalanı, kullandığım denetim sırası ve her gözlemi üreten komuttur.

Bağlama gerçekte neyi belirler

Bağlama, sokete yerel bir adres atar. Ardından çekirdek, bir ilke kuralı bu aramanın hangi tabloyu okuduğunu değiştirmedikçe, aksi halde yapacağı aynı rota aramasını yapar.

Bu yüzden bir paket fiziksel arabirimde VPN kaynak adresiyle çıkabilir. Karşı tarafta, ağın o yolda hiç beklemediği özel bir aralıktan gelir, dönüş trafiğinin geri dönüş rotası yoktur ve bağlantı askıda kalır veya sıfırlanır.

Linux IP soketleri başvurusu bağlamanın anlamını belgeler. Yönlendirme yarısı ip-rule ve ip-route içinde yaşar ve bunlar bir nedenle ayrı kılavuzlardır.

Adresin bu ad alanına ait olduğunu doğrulayın

Bağlanabileceğiniz bir adres, uygulamanın çalıştığı ağ ad alanının içindeki bir arabirimde bulunmalıdır. Eş adresi, ağ geçidi adresi veya yalnızca başka bir ad alanında bulunan bir adres bağlanamaz ve çağrı EADDRNOTAVAIL ile başarısız olur.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Bu üçünü uygulamayla aynı bağlamda çalıştırın: aynı ad alanı ve alabiliyorsanız aynı kullanıcı. Eski bir net30 şeması, mevcut topolojinizin istemciye hangi adresi verdiğinin kanıtı değildir. Gerçekten etkin olan arabirimi okuyun.

O kaynak ve hedef için aramayı okuyun

Tek bir komut, bağlamanın yanıtlamadığı soruyu yanıtlar:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

İlk satır, o kaynaktan o hedefe gidecek bir paketin izleyeceği rotayı, çıkış arabirimi ve tercih edilen kaynakla birlikte yazdırır. Fiziksel arabirimi adlandırıyorsa, bağlama ile rota çelişir ve paket, yolun geri dönemediği bir kaynakla çıkar.

Ardından ip rule show, herhangi bir kuralın başka bir tablo seçip seçmeyeceğini söyler. Burada öncelikler önemlidir, çünkü ilk eşleşen kural kazanır ve sizinkinin üstünde her şeyi yakalayan bir kural sizinkini görünmez kılar.

İlke kuralını yalnızca tasarım buysa kurun

Kaynak tabanlı yönlendirme bilinçli bir tasarımdır, tek bir uygulama için onarım değildir. İlke sahibi tünel alt ağının trafiğinin tüneli kullanmasını istiyorsa, kural onun yapılandırmasına aittir, dizüstü bilgisayarınızdaki tek seferlik bir komuta değil.

İşleyen biçim, tünel üzerinden varsayılan rotası olan özel bir tablo artı VPN kaynak aralığını o tabloya gönderen bir kuraldır. Tasarımın gerektirdiği istisnaları ekleyin, çünkü yalnızca tünel varsayılanı içeren bir tablo yerel kalması veya fiziksel yoldan erişilmesi gereken hedefleri de yakalar.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

ip rule del ve ip route flush table 100 ile geri alın. Bu şekilde eklenen her şey, bir yönetici yazmadıkça yeniden başlatmada kaybolur; bu hem bir güvenlik özelliği hem de tek kopyayı kabuk geçmişinizde tutmamak için bir nedendir.

Üç gözlemle doğrulayın

Uygulamanın istediği kaynağı, aramanın seçtiği rotayı ve sunucunun gerçekte gördüğü kaynağı kaydedin.

Bu üçü birbirini tutmayabilir ve her uyuşmazlık başka bir yeri işaret eder. Tünel arabirimindeki yakalama, paketin doğru kaynakla çıktığını kanıtlar. Fiziksel arabirimdeki yakalama, yanlış yoldan çıktığını kanıtlar. Yolu uçtan uca kanıtlayan tek görünüm sunucu tarafıdır.

Uygulama aygıta bağlama seçeneği veya uygulama başına yönlendirme kipi sunuyorsa, bunu farklı kısıtları olan farklı bir mekanizma olarak ele alın. Benzer görünen ayarların tümü aynı çekirdek kararına varmaz.