WireGuard ile Docker ağları çakışıyor, routing'i nasıl stabilize ederim?

Kısa cevap: Kök neden çakışan RFC1918 aralıkları. Çözüm runtime hilesi değil, deterministik bir adresleme planı: Docker’ın havuzunu sabitle, WireGuard’ın AllowedIPs’ini daralt, rotaları kalıcı yap.

Bu bir “rota bug’ı” değil, bir planlama sorunu: WireGuard ayağa kalkınca aynı 172.x/10.x aralığına oturan iki ağ var ve çekirdek hangisini routing yapacağını şaşırıyor.

1. Docker’ın havuzunu sabitle. daemon.json içinde default-address-pools ile Docker’ın otomatik ağ atadığı bloğu, WireGuard subnet’iyle asla çakışamayacak bir aralığa pinle. Docker rastgele subnet seçtikçe çakışma kaçınılmaz; bunu elinle belirle.
2. WireGuard’a DAR AllowedIPs ver. AllowedIPs yalnızca DB subnet’i olsun — 0.0.0.0/0 değil. Geniş tutarsan WireGuard host’un tüm default rotasını ele geçirir (route hijack) ve her şey tünelden akmaya çalışır. Daraltınca çekirdek sadece DB trafiğini wg0’a yollar.
3. Rotaları kalıcı yap. ip route add ad-hoc komutları reboot’ta uçar. Rotaları systemd-networkd/netplan ile tanımla ki yeniden başlatmada otomatik gelsin. “Çalışıyordu, sonra restart’ta bozuldu” derdinin tek kalıcı çözümü bu.
4. DB kutusunu sadece wg0 üzerinden inbound tut. Veritabanını dünyaya NAT’lama; yalnızca tünelden gelen bağlantıyı kabul etsin. Dışa kapalı kümenin anlamı bu — erişim tek kapıdan, o kapı da WireGuard.
5. Doğrula. ip route get <db-ip> ile paketin gerçekten wg0’dan çıktığını, wg show ile handshake’in canlı olduğunu gör. Tahminle değil, bu iki komutla teyit et.

Sonuç: Çakışmaları runtime’da kovalamayı bırak; bu bir planlama problemi. Ben olsam her arayüz için (ens192 / docker0 / wg0) belgelenmiş, çakışmayan bir subnet planı yazardım. Docker havuzunu pinle, AllowedIPs’i daralt, rotaları systemd ile kalıcı kıl, DB’yi sadece tünelden eriş. Adresleme planı netse routing kendiliğinden stabil olur.