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

> Çakışma runtime hatası değil adresleme planı sorunudur: Docker havuzunu daemon.json'da pinleyin, AllowedIPs'i DB subnet'ine kısın, rotaları kalıcı yapın.

- Soruldu: 2026-05-04
- Yanıtlandı: 2026-05-08
- Soran: Mert
- Etiketler: altyapi, networking, docker
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/wireguard-ile-docker-agi-ip-cakismasi-ve-routing/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Ubuntu VPS'imde dışa kapalı bir veritabanı kümesi var; ana arayüz `ens192`. Güvenli erişim için bir WireGuard tüneli kurdum. VPN ayağa kalkınca yerel Docker ağları (`docker0`) ile WireGuard alt ağları arasında IP çakışması ve routing hataları çıkıyor.

Sunucu düzeyinde network izolasyonunu ve routing tablosunu kalıcı olarak 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'ye sadece tünelden eriş. Adresleme planı netse routing kendiliğinden stabil olur.

## İlgili Yazılar

- [Docker sanallaştırma: kurulum ve temel kullanım](/blog/docker-sanallastirma-teknolojisi-kurulum-kullanim/) — Blog
- [Docker imaj boyutunu multi-stage build ve distroless ile nasıl küçültürüm?](https://www.muhammetsafak.com.tr/sor-bakalim/docker-imaj-boyutunu-multi-stage-ve-distroless-ile-kucultmek/) — Sor Bakalım
- [HTTP/2 ve HTTP/3 (QUIC) API performansını nasıl etkiler?](https://www.muhammetsafak.com.tr/sor-bakalim/http-2-ve-http-3-quic-api-performansina-etkisi/) — Sor Bakalım
- [Container'ı non-root çalıştırınca mount edilen storage dizinine yazamıyorum, izinleri nasıl çözerim?](https://www.muhammetsafak.com.tr/sor-bakalim/containeri-non-root-calistirinca-mount-edilen-storage-dizinine-yazamiyorum-izinleri-nasil/) — Sor Bakalım
