Ağ ad alanında WireGuard: soket neden geride kaldı

Arayüz istediğiniz ad alanında listeleniyor, uygulama ona bağlı, yine de tünel trafiği hiç görünmüyor. Bu, Linux çekirdeğindeki bir WireGuard cihazının bir ad alanında oluşturulup başka birine taşınmasının imzasıdır: arayüz taşındı, şifreli UDP soketi taşınmadı. İç trafik anlam kazanmadan önce ikisi de doğru yerde olmalı. Bir yerine iki bağlama bakmanız gerektiğini bildiğinizde kontrol hızlıdır.

Belirti: doğru ad alanı, paket yok

Ad alanının içinde tünel sağlıklı görünüyor. Cihaz var, adresler atanmış ve eş yapılandırması mevcut. Dışarıda, beklenen UDP alışverişi izlediğiniz arayüzde hiç görünmüyor ve karşı taraf el sıkışma olmadığını bildiriyor.

Neden, uygulamanın iç paketlerinin taşınan cihaza ulaşması ve cihazın bunları başka bir ağ bağlamına ait bir soket üzerinden göndermeye çalışmasıdır. Kullandığı alt katman rotası ve buna uygulanan her güvenlik duvarı kuralı, cihazın oluşturulduğu ad alanındakilerdir.

Bu ne taşıma hatası ne de eşin yanlış yapılandırmasıdır. Çekirdek uygulaması böyle çalışır ve WireGuard için ad alanı belgeleri oluşturma kuralını doğrudan açıklar.

Soketin neden bir doğum yeri var

Bir WireGuard cihazı şifreli taşıması için tek bir UDP soketine sahiptir ve bu soket cihazın oluşturulduğu ad alanında açılır. Arayüzü bir bağlantı komutuyla taşımak görünen cihazı taşır ama taşımayı başladığı yerde bırakır. Sonra iki nesnenin sahipleri farklı olur.

Sonucu kaçırmak kolaydır çünkü iki yarı farklı yerlerde incelenir. İç rota uygulamanın çalıştığı ad alanında belirlenir, dış rota soketin yaşadığı yerde belirlenir. Yalnızca birini kontrol etmek kendinden emin ama yanlış bir sonuç verir. İkisini kontrol etmek genellikle soruşturmayı tek geçişte bitirir.

Soketi istediğiniz yerde oluşturun

Çözüm, cihazı dışarıda oluşturup taşımak yerine hedef ad alanının içinde oluşturmaktır. Onaylanmış bir ad alanının zaten var olduğunu ve adın kullanılmadığını varsayarak:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

Artık hem arayüz hem de soketi o bağlama aittir, dolayısıyla alt katman rotası ve geçerli filtreleme kuralları orada yapılandırılmış olanlardır. Tasarım açık tarafı başka bir yerde gerektiriyorsa önce temel arayüzü ad alanına koyun, sonra tüneli oluşturun. Sıra tasarımın parçasıdır, uygulama ayrıntısı değildir.

Bunları ağ yönetimi komutları olarak görün, tarif olarak değil. Bir cihaz oluşturur ve durumu gösterir; anahtarlar, eşler, adresler ve rotalar yine de onaylanmış bir yapılandırmadan gelmelidir ve mevcut bir üretim arayüzü asla bir örnekte değiştirilmemelidir.

Yolun iki tarafını okuyun

Cihaz doğru yerdeyken iki kararı ayrı ayrı doğrulayın. Uygulamanın bağlamından iç aramayla başlayın, ardından soketin sahibi bağlamdan dış yolu kontrol edin:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

İç arama tünel üzerinden çözülürse ve dış yakalama şifreli alışverişi gösterirse iki yarı uyuşur. Yakalama boşsa soket hâlâ başka bir yerdedir ya da ad alanındaki alt katman rotası uç noktaya ulaşmıyor.

Bir kontrol daha kayda girmelidir: cihaz yeniden başlatmadan sonra nasıl oluşturulur. Arayüzü farklı bir oluşturma bağlamıyla yeniden oluşturan yönetici soketin doğum yerini değiştirir. Bir kez çalışan elle taşıma, yönetilen yol hakkında kanıt değildir.