İç içe WireGuard: orta atlama kendi bağlantı noktasını yanıtlayamıyor
Orta atlama her şeyi tek bir tünele gönderdiğinde, gelen hizmetine verilen yanıtlar yanlış yoldan çıkar. Arayüzdeki kaynak bağlantı noktası kuralı bunu düzeltir.
Üç WireGuard atlaması genel adresi olmayan bir ağa ulaşır ve sonra orta makine dinlemesi gereken bağlantı noktasında yanıt vermeyi bırakır. İlerideki tünel hâlâ çalışıyor, uzak ana bilgisayar hâlâ yanıt veriyor ve dışarıdan susan yalnızca orta sunucunun kendisi. Bu birleşim kafa karıştırıcı çünkü kendi kendine yol açılmış: orta atlama kendi yönlendirme tablosuna uyuyor ve tablo yanıtlarını yanlış yöne gönderiyor.
Orta kutunun kendisiyle konuşana kadar çalışan bir zincir
Örnek bir zincir alalım: istemci A, UDP 500 üzerinden B sunucusuna ulaşır ve B, UDP 500 üzerinden C sunucusuna devam eder. C yalnızca tek eşinin adresinden trafik kabul eder, bu da onu bir yaprak yapar ve davranışını basit tutar. B yaprak değildir ve bu arızanın ilginç yanı tam olarak orada gerçekleşir.
Bu ayrım önemlidir çünkü yaprak ve orta rolleri zıt yönlere çeker. Bir yaprak her şeyi tek bir tünele sonuç doğurmadan gönderebilir, çünkü ona başka hiçbir şey bağlı değildir. Orta atlama aynı anda istemciler için bir uç nokta ve uzak tarafa doğru bir istemcidir, ve bu iki iş farklı yönlendirme ister.
Yanıt neden tünelden çıkıyor
B üzerinde, C’ye bakan arayüz eşleşen varsayılan yolla birlikte AllowedIPs = 0.0.0.0/0 taşır. Bu yüzden B’nin oluşturduğu her paket, daha belirgin bir şey öncelik almadıkça o tünele girer.
A’dan B’ye adreslenmiş bir paket gelir ve kabul edilir, çünkü B hedeftir ve yerel teslimat önce gerçekleşir. Yanıt, A’nın genel adresine yönelmiş tamamen yeni, yerel olarak üretilmiş bir pakettir ve bu hedef tünel içindeki varsayılan yolla eşleşir. C onu alır, o adrese sahip değildir ve düşürür.
Belirti güvenlik duvarı sorunu ya da anahtar uyuşmazlığı gibi okunur ve burada ikisi de doğru değildir. C’ye doğru tünelde alınan bir yakalama, yanıtların yanlış yöne gittiğini gösterir. O tek gözlem, herhangi bir miktarda yapılandırma okumaktan daha fazla zaman kazandırır, bu yüzden anahtarları değiştirmeye başlamadan önce onu yazın. Yakalamayı görmeyen herkes tünelin kendisinin bozuk olduğunu varsayacaktır.
Dar onarım: kaynak bağlantı noktasıyla eşleşen ilke kuralları
B’nin dinleyen soketinden gelen yanıtlar kaynak bağlantı noktası 500 ile çıkar. Bir ilke kuralı bununla eşleşip o paketleri normal tabloya geri gönderebilir:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101İlke kuralları öncelik sırasına göre sorgulanır ve ana tablo 32766’da durur, bu yüzden 100’deki bir kural tünelin varsayılan yolu söz sahibi olmadan önce sorulur. Dışarıdan erişilebilir kalması gereken her bağlantı noktası için bir giriş ekleyin ve fazlasını değil, böylece iletilen trafik yapıldığı tüneli kullanmaya devam eder.
Bu hilenin sınırını bilin. sport seçicisi yerel olarak üretilen paketlerle eşleşir, bu da tam olarak yanıt durumunu kapsar ve B’nin yalnızca başkası için ilettiği trafiği bilerek kapsamaz. B’nin arkasında barındırılan bir hizmet hâlâ kendi yanıtına ihtiyaç duyar ve bunun tersini iddia etmek ilk hizmet için çalışan ve ikincisi için başarısız olan bir düzeltme üretir.
Kurala bir sahip verin
İstem satırına yazılan bir kural, arayüz bir sonraki yeniden oluşturulduğunda kaybolur. Bir WireGuard kurulumunda, arayüzün oluşturulduğu ve kaldırıldığı yere koyun:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Arayüzün sahibi NetworkManager, bir dağıtım kancası veya bir konteyner giriş noktasıysa, çift elde düzenlenmiş bir dosyaya değil o sahibe aittir. Etkin kuralları yeniden bağlandıktan sonra denetleyin, yalnızca ilk başlatmadan sonra değil, çünkü ilk başlatma her zaman çalışan durumdur.
Alternatifleri dürüstçe karşılaştırın
Kaynak bağlantı noktası kuralı dört çıkış yolundan biridir ve en dar olanıdır. Tünel ilkesine hiç dokunmama avantajı vardır, bu yüzden genellikle sonraki değişiklikleri atlatır. Dar onarımlar da geçerliliğini yitirdiğinde yüksek sesle başarısız olur, oysa geniş bir istisna nedeni ortadan kalktıktan çok sonra bile sessizce çalışmaya devam eder. İki yıl sonra kutunun sahibi başkası olduğunda bu fark zarafetten daha önemlidir.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
Seçtikten sonra iki uçtan da doğrulayın. A’dan B’nin bağlantı noktasına bir bağlantı başlatın ve bir süre meşgul tutun. B üzerinde çekirdeğin yanıt yolunu ip route get <address-of-A> sport 500 benzeri bir şeyle gerekçelendirmesini sağlayın ve tüneli değil WAN arayüzünü adlandırdığını doğrulayın. Ardından, C’nin arkasındaki bir şeyin hâlâ zincir üzerinden yanıt verdiğini denetleyin, bu da istisnanın atlatmaya dönüşmek yerine dar kaldığını kanıtlar. Son olarak bağlantı noktalarını tasarım notlarına kaydedin, yoksa bir sonraki operatör bunu başka bir hizmette yeniden keşfeder.