Bir Linux sürecini WireGuard tünelinin dışında çalıştırma

Bir programı, yolları düzenleyerek tam tünelli bir WireGuard ana bilgisayarından muaf tutamazsınız. Yollar, hedefe göre bir yol seçer ve muaf tutmak istediğiniz şey bir süreçtir, bu yüzden çekirdeğin karşılaştıracağı bir şey yoktur. İşleyen yaklaşım, o sürece kendi ağ bağlamını vermektir: kendi arayüzü, adresleri ve varsayılan yolu olan bir ad alanı, ana bilgisayara bir veth çiftiyle bağlanmış. Bunu Ubuntu 24.04 üzerinde wireguard-tools 1.0.20210914 ile çalıştırdım ve ad alanı hiçbir zaman sorun olmadı — sorun, ana bilgisayarın yönlendirme politikası ve tünelin işaretleme kurallarıydı.

Önce ihtiyacınız olan bağlam türünü seçin

Uygulamada iki biçim ortaya çıkar. Ana bilgisayar tam bir tünel çalıştırıyorsa ve bir programın ISP yolundan çıkması gerekiyorsa, ikinci bir ad alanı kurarsınız, onu ana bilgisayara bağlarsınız ve ana bilgisayarın onun için trafiği yönlendirmesine ve çevirmesine izin verirsiniz. Bir ad alanı zaten bir VPN arayüzü taşıyorsa ve yalnızca içinde başlatılan bir komuta ihtiyacınız varsa, bu olağan ip netns exec durumudur ve yönlendirme işinin çoğu zaten yapılmıştır.

Biçimlerin hiçbiri size tek bir süreç kimliğiyle sınırlı bir kural vermez. Netfilter adresleri, bağlantı noktalarını, işaretleri ve arayüzleri eşleştirir; süreç başına bir yönlendirme tablosu yoktur. İşaretleme trafiği yönlendirebilir, ancak işaret zaten tanımladığınız paketlere konmalıdır ve bu, bir katman aşağıdaki aynı sorundur. Ad alanı, o süreç ağacı için tüm yığını ayırır ve bu yüzden olağan yanıt budur.

Gereksinim gerçekten tünelden hiçbir şeyin çıkmamasıysa, bunun yerine tüneli durdurun. Ad alanı karışık durum için vardır: bir program dışarı, geri kalan her şey içeri, aynı makinede, aynı anda.

İkinci bağlamı kurun ve ana bilgisayara bağlayın

Örnek bir düzen: ana bilgisayarda varsayılan yolu taşıyan bir WireGuard arayüzü ve clearnet adlı bir ağ ad alanı var, veth çiftiyle ana bilgisayara bağlı. Aşağıdaki adresler örnektir.

ip netns add clearnet
ip link add veth-clear-out type veth peer name veth-clear-in
ip addr add 192.168.100.1/24 dev veth-clear-out
ip link set veth-clear-out up
ip link set veth-clear-in netns clearnet
ip netns exec clearnet ip addr add 192.168.100.2/24 dev veth-clear-in
ip netns exec clearnet ip link set veth-clear-in up
ip netns exec clearnet ip route add default via 192.168.100.1

Bu ad alanı artık ana bilgisayara ulaşabilir ve başka hiçbir yere ulaşamaz. Ana bilgisayar trafiği yönlendirmeli ve kaynak adresini yeniden yazmalıdır, çünkü 192.168.100.0/24 özeldir ve üstteki yönlendiricinin içine geri dönüş yolu yoktur:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <wan-interface> -j MASQUERADE

Devam etmeden önce ad alanı tarafını doğrulayın.ip netns exec clearnet ip route veth yolunu ve 192.168.100.1 üzerinden varsayılan yolu göstermeli, o adrese ping yanıt vermelidir. Ana bilgisayarın adresine ping başarısız olursa adresler veya bağlantı durumu yanlıştır ve hiçbir güvenlik duvarı kuralı yardımcı olmaz.

Adlar çözülüyor ama hiçbir şey geri dönmüyorsa FORWARD'ı okuyun

Klasik başarısızlık bir yönlendirme hatası gibi görünür: ad alanı bir adı çözer, paket çıkar ve yanıt asla gelmez. FORWARD politikası DROP olan ana bilgisayarlarda — birkaç dağıtım ve çoğu sertleştirilmiş imaj bunu yapar — paket yolda düşürülür ve uygulamanın yazdırdığı hata filtreleme hakkında hiçbir şey söylemez.

Bir şey eklemeden önce zinciri okuyun:

iptables -S FORWARD
nft list chain inet filter forward

Sonra trafiği iki yönde geçirin, sayaçlarla, böylece kuralın hiç eşleşip eşleşmediğini görebilirsiniz:

iptables -A FORWARD -i veth-clear-out -o <wan-interface> -j ACCEPT
iptables -A FORWARD -i <wan-interface> -o veth-clear-out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
watch -n1 'iptables -L FORWARD -v -n'

Sıfır paket sayacı olan bir kural yolda değildir. Ya arayüz adları varsayımınızdan farklıdır ya da zincirdeki daha önceki bir kural paketi ilk olarak kabul etmiş, düşürmüş veya geri göndermiştir. Sırayı düzeltin, kuralın metnini değil.

Yanıt trafiği insanların unuttuğu yarıdır. Dönüş kuralı aynı veth adını artı bağlantı durumu eşleşmesini gerektirir, ya da politikayı açık tutuyorsanız basit bir arayüz kabulünü. Yalnızca giden kuralı ekleyin ve özgün belirti geri döner, yeni kuralınız orada durur ve doğru görünür.

Tünelin işaretleme kurallarını yeni yoldan uzak tutun

Bu adım, çalışan bir ad alanını sızdıran bir ad alanına dönüştürür. WireGuard kurulumları genellikle kendi yönlendirme kuralları ve özel bir tabloyla birlikte bir güvenlik duvarı işareti politikası kurar, böylece işaretsiz paketler ana tabloya geri düşerken işaretli paketler tünel tablosunu kullanır. Ad alanından yönlendirilen trafik çıkarken politika yönlendirmesine göre değerlendirilir ve bu kuralların nasıl yazıldığına bağlı olarak tünel tablosuna düşebilir.

İki ekleme yolları ayırır. Ad alanının alt ağı için mangle zincirinde erken dönün ve o alt ağı ana tabloya koyan kaynak tabanlı bir kural ekleyin:

iptables -t mangle -I PREROUTING -s 192.168.100.0/24 -j RETURN
ip rule add from 192.168.100.0/24 lookup main priority 100

Öncelik 100 benim makinemde tünel kurallarından önce sıralanır, bu yüzden o kaynak için normal tablo karar verir. Sayıyı körü körüne kopyalamayın:wg-quick kurduğu öncelikler sürümler arasında ve IPv4 ile IPv6 kurulumları arasında farklıdır, bu yüzden çalıştırın ip rule show ve makinenizde tünel kurallarından önce gelen bir öncelik seçin.

Kural listesine güvenmek yerine kaynağa özgü bir aramayla doğrulayın:

ip route get 1.1.1.1 from 192.168.100.2
ip netns exec clearnet ip route get 1.1.1.1

İlk komut WireGuard arayüzünü bildiriyorsa, yeni kural henüz tünel politikasının önünde değildir. WAN arayüzünü bildiriyor ve ikincisi hâlâ veth varsayılanını gösteriyorsa, ana bilgisayar ile ad alanı anlaşmazlık içindedir ve iki yönlendirme tablosunu yeniden okumalısınız.

Bağlantıyı açan süreci başlatın

Komutu başlatmak tek satırdır, ama soketi gerçekten oluşturan süreci başlatın.ip netns exec clearnet curl -s https://ifconfig.me en küçük dürüst testtir: ad alanının dünyaya sunduğu adresi gösterir, ana bilgisayarın kullanacağını değil.

Bir hizmet için ad alanını yola göre bağlayın ki süreç ömrü boyunca içinde kalsın:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Grafik uygulamalar, tek satırlık yaklaşımın sessizce başarısız olduğu yerdir. Menüden başlatılan bir tarayıcı isteği genellikle ad alanının dışında zaten çalışan bir örneğe verir, bu yüzden yeni pencere görünür ve trafik yine tünelden çıkar. Gerçekten yeni bir örneğin oluşması için ona ayrı bir profil verin, sonra tahmin etmek yerine süreç bağlamını kontrol edin:

readlink /proc/$(pgrep -f clearnet-profile | head -1)/ns/net
readlink /run/netns/clearnet

İki çıktı eşleşmelidir. Aynı kontrol her uzun süreli program için çalışır ve başlatıcının istediğinizi yaptığını varsaymak yerine uygulama başına bir kez yapmaya değer.

Ad çözümlemesi kendi kararını gerektirir. Bir ad alanı oluşturmak ona bir çözümleyici yapılandırması vermez; ad alanı başına dosyalar şunun aracılığıyla desteklenir /etc/netns/<name>/resolv.conf ve o olmadan yanlış okunması kolay bir davranışı devralırsınız. IPv6 aynı muameleyi gerektirir: ad alanının v6 varsayılan yolu yokken uygulama v6'yı tercih ediyorsa, istekler geri çekilmeden önce takılabilir, bu da bozuk bir tünel gibi görünür.

Çerçeveyi kontrol edin, yalnızca çıkış adresini değil

Çalışan bir genel adres yolu kanıtlar, tüm gereksinimi değil. Geri kalanı bu sırayla geçin:

• ip netns exec clearnet ip route get 1.1.1.1 veth varsayılanını gösterir, WireGuard arayüzünü değil.
• Bir istek sürerken iki kuralın FORWARD sayaçları artar.
• Uygulama süreci beklediğiniz ad alanı inode'unu bildirir.
• Yeniden başlatmadan sonra ad alanı hizmet başlamadan önce vardır; daha erken çalışan unit başarısız olur ya da daha kötüsü ad alanının dışında çalışır.

Sonra tünel düştüğünde ne olması gerektiğine karar verin. Ad alanı çalışmaya devam eder, bu alıştırmanın amacı ve aynı zamanda riskidir: muaf tutulan program bağlı kalırken diğer her şey durur. Bunu bir politika seçimi olarak kaydedin ve muafiyetin neyi kapsamadığı konusunda açık olun — hesap kimliği, kaydedilmiş tarayıcı durumu ve DNS sağlayıcınız bir ağ ad alanının kapsamı dışındadır ve muafiyeti anonimlik olarak görmek yapılandırmadan daha uzun yaşayan hatadır.