Docker Ağ Yapılandırması: Bridge, Host ve Macvlan Farkı

Kısa cevap: Docker ağ modu, konteynerin ağ üzerinde nasıl konumlanacağını belirleyen sürücüdür; beş mod vardır ama pratikte üçü kullanılır. Kullanıcı tanımlı bridge varsayılan tercihtir: konteynerler birbirine servis adıyla erişir, ağlar izoledir. Host modu ana sistemin ağ yığınını doğrudan kullanır ve izolasyonu feda eder. Macvlan konteynere fiziksel ağda kendi IP adresini verir.

Docker ağ modelleri: hangisi ne yapar?

Mod	Konteyner ağda nasıl görünür	İzolasyon	Tipik kullanım
bridge (kullanıcı tanımlı)	Ana sistemin arkasında, NAT ile	İyi	Varsayılan tercih, uygulama yığınları
bridge (varsayılan docker0)	Aynı, ama isim çözümleme yok	Zayıf	Kullanmayın
host	Ana sistemle aynı ağ yığını	Yok	Ağ araçları, çok portlu servisler
macvlan	Fiziksel ağda ayrı bir cihaz gibi	Orta	Yayın trafiği, eski protokoller
none	Ağ yok	Tam	Ağa ihtiyacı olmayan işler

Karar akışı basittir: önce kullanıcı tanımlı bridge deneyin. Uygulamanın gerçekten ana sistemin ağ yığınına ihtiyacı varsa host, fiziksel ağda ayrı bir cihaz olarak görünmesi gerekiyorsa macvlan.

Kullanıcı tanımlı bridge: neden varsayılan tercih?

Docker kurulduğunda docker0 adında bir varsayılan köprü oluşur. Hiçbir ağ belirtmeden konteyner çalıştırdığınızda buraya bağlanır. Sorun şu: bu ağda isim çözümleme yoktur. Bir konteynerden diğerine erişmek için IP adresi kullanmanız gerekir ve o IP, konteyner yeniden oluşturulduğunda değişir.

Kullanıcı tanımlı bir ağ bu sorunu çözer. Docker’ın dahili DNS sunucusu, konteyner adlarını güncel IP adreslerine çözer:

# Kullanıcı tanımlı ağ oluştur
docker network create uygulama-agi

# İki konteyneri aynı ağa bağla
docker run -d --name db --network uygulama-agi postgres:16.4
docker run -d --name web --network uygulama-agi benim-uygulamam:1.4.2

Artık web konteyneri veritabanına db:5432 adresiyle erişir. IP adresi bilmesine gerek yoktur, konteyner yeniden oluşturulsa da ad değişmez.

Compose kullandığınızda bu zaten otomatiktir; her proje için kullanıcı tanımlı bir ağ oluşturulur ve servisler birbirine servis adıyla erişir:

services:
  db:
    image: postgres:16.4
    networks: [arka-uc]
    # port yayımlamaya GEREK YOK

  web:
    image: benim-uygulamam:1.4.2
    environment:
      DATABASE_URL: postgres://kullanici:parola@db:5432/veritabani
    ports:
      - "127.0.0.1:3000:3000"
    networks: [arka-uc]

networks:
  arka-uc:

Buradaki en önemli satır, olmayan satırdır: veritabanı portu hiç yayımlanmamıştır. Uygulama ona iç ağ üzerinden erişir; dışarıdan erişilemez. Bu, en yaygın güvenlik hatasının doğrudan çözümüdür.

Konteyner ağları nasıl segmentlere ayrılır?

Kullanıcı tanımlı ağların ikinci faydası izolasyondur: farklı ağlardaki konteynerler birbirini göremez. Bunu, klasik ağ tasarımındaki DMZ mantığıyla aynı biçimde kullanabilirsiniz.

services:
  vekil:
    image: traefik:v3.1
    ports:
      - "80:80"
      - "443:443"
    networks: [on-uc]

  web:
    image: benim-uygulamam:1.4.2
    networks: [on-uc, arka-uc]      # iki ağda birden

  db:
    image: postgres:16.4
    networks: [arka-uc]             # yalnız arka uçta

networks:
  on-uc:
  arka-uc:
    internal: true                  # bu ağ dış dünyaya çıkamaz

Bu yapıda ters vekil sunucu veritabanını göremez; yalnız uygulama sunucusuna erişebilir. Veritabanı ağı internal: true ile işaretlendiği için dışarıya giden bağlantı da kuramaz. Ele geçirilmiş bir ön uç bileşeni, doğrudan veritabanına ulaşamaz ve veriyi dışarı sızdıramaz.

Aynı mantığın fiziksel ağdaki karşılığı VLAN segmentasyonudur; MikroTik VLAN ile ağ izolasyonu ve Proxmox ağ yapılandırması yazılarında aynı ilkenin ağ katmanındaki uygulamasını anlattım. Katman değişir, ilke değişmez: her bileşen yalnız işini yapmak için gereken yere erişebilmeli.

Host modu: ne zaman gerçekten gerekli?

Host modunda konteyner, ana sistemin ağ yığınını doğrudan kullanır. Kendi IP adresi ve kendi ağ ad alanı yoktur; dinlediği port doğrudan ana sistemin portudur.

services:
  izleme-ajani:
    image: izleme-araci:1.0
    network_mode: host

Gerçekten gerekli olduğu durumlar:

• Ağ izleme araçları: ana sistemin arayüzlerini görmesi gereken ajanlar.
• Çok sayıda port dinleyen servisler: onlarca portu tek tek yayımlamak yerine host modu pratiktir.
• Yayın ve çoklu yayın trafiği: ağ keşif protokolleri NAT arkasından düzgün çalışmaz.
• Ağ performansının kritik olduğu durumlar: NAT katmanı atlanır.

Bedeli açıktır: izolasyon yoktur. Konteyner ana sistemin tüm ağ arayüzlerini görür, dinlediği her port doğrudan dışarı açılır ve 127.0.0.1 üzerinde dinleyen diğer servislere erişebilir. Sunucuda yalnız yerelden erişilebilir olduğunu düşündüğünüz bir veritabanı, host modundaki bir konteyner için erişilebilir demektir.

Kural: host modunu son çare olarak kullanın ve o konteyneri güven sınırının içinde sayın. Güvenlik değerlendirmesinin tamamı Docker güvenlik sertleştirme yazısında.

Macvlan ne işe yarar, ne zaman gerekir?

Macvlan, konteynere fiziksel ağ üzerinde kendi MAC adresini ve kendi IP adresini verir. Ağdaki diğer cihazlar için konteyner, ayrı bir fiziksel makine gibi görünür.

docker network create -d macvlan \
  --subnet=192.168.10.0/24 \
  --gateway=192.168.10.1 \
  -o parent=enp1s0 \
  fiziksel-ag

docker run -d --name servis --network fiziksel-ag --ip 192.168.10.50 imaj:1.0

Kullanışlı olduğu yerler: yayın trafiğine dayanan servisler (ağ keşfi, bazı medya sunucuları), eski protokoller, ve konteynerin ağda kendi IP’siyle görünmesinin gerektiği durumlar.

Üç kısıtı bilin:

1. Ana sistem ile konteyner doğrudan haberleşemez. Bu, macvlan’ın en çok şaşırtan davranışıdır: aynı fiziksel arayüzü paylaştıkları hâlde ana sistemden konteynere ping atamazsınız. Çözümü, ana sistemde ayrı bir macvlan alt arayüzü tanımlamaktır.
2. Switch tarafı desteklemeyebilir. Bazı switch’ler tek portta birden fazla MAC adresine izin vermez (port güvenliği); kablosuz arayüzlerde macvlan genellikle çalışmaz.
3. IP yönetimi sizde. Konteynere verdiğiniz adresin DHCP havuzuyla çakışmaması gerekir. Çakışan adres, ağda teşhisi zor kesintiler üretir.

Çoğu senaryoda macvlan’a ihtiyaç yoktur; bridge artı port yayımlama aynı işi daha az sürprizle yapar. Gerçekten ağda ayrı bir cihaz gerekiyorsa, konteyner yerine hafif bir sanal makine de değerlendirilmelidir; karşılaştırma LXC, Docker ve sanal makine yazısında.

Port yayımlamak firewall kurallarını neden etkisiz kılar?

Bu, Linux sunucu güvenliğindeki en yaygın açığın kaynağıdır ve tekrar edilmeyi hak eder.

ports:
  - "5432:5432"              # YANLIŞ: tüm arayüzlerde dışarı açık
  - "127.0.0.1:5432:5432"    # DOĞRU: yalnız yerelden

Docker, yayımlanan portlar için doğrudan çekirdeğin NAT tablosuna kural ekler; bu kurallar ufw’nin filtre zincirinden önce değerlendirilir. Sonuç: ufw status çıktısı kapalı gösterse bile port dışarıdan erişilebilir olur.

Karar sırası:

1. Konteynerler arası iletişim mi? Port yayımlamayın, aynı ağa koyun ve servis adıyla erişin.
2. Yalnız ana sistemden mi erişilecek? 127.0.0.1: ön ekiyle yayımlayın.
3. Dışarıya sunulacak mı? Ters vekil sunucu üzerinden yayımlayın; seçenekler nginx, Traefik ve Caddy karşılaştırmasında.

Gerçekte ne açık olduğunu düzenli kontrol edin:

sudo ss -tulpn | grep LISTEN
# 0.0.0.0:PORT satırlarının her biri bilinçli bir karar olmalı

Firewall ile Docker etkileşiminin tamamı Linux firewall rehberinde.

Ağ teşhisi: sorun nerede?

Konteyner ağ sorunlarını katman katman daraltın.

# 1) Hangi ağlar var, hangi konteynerler bağlı
docker network ls
docker network inspect uygulama-agi

# 2) Konteyner hangi ağlarda ve hangi IP'de
docker inspect --format '{{json .NetworkSettings.Networks}}' web | python3 -m json.tool

# 3) Konteyner içinden isim çözümleme çalışıyor mu
docker compose exec web getent hosts db

# 4) Konteynerden hedefe erişim var mı (araç yoksa geçici konteynerle)
docker run --rm --network uygulama-agi nicolaka/netshoot nc -zv db 5432

# 5) Ana sistemde dinleyen portlar
sudo ss -tulpn | grep LISTEN

Teşhis sırası:

1. İki konteyner aynı ağda mı? Farklı ağlardaysa birbirlerini göremezler; en sık sebep budur.
2. İsim çözümleniyor mu? Çözülmüyorsa muhtemelen varsayılan bridge ağındasınız.
3. Hedef servis gerçekten dinliyor mu? Konteyner içindeki uygulama 127.0.0.1 üzerinde dinliyorsa, ağdaki diğer konteynerler erişemez; uygulamanın 0.0.0.0 üzerinde dinlemesi gerekir. Bu ayrım, konteyner içinde ile konteyner dışında farklı anlamlara gelir ve sık karıştırılır.
4. Firewall veya ağ izolasyonu engelliyor mu? internal: true işaretli bir ağdaki konteyner dış dünyaya çıkamaz.

Üçüncü madde özellikle kafa karıştırıcıdır: ana sistemde 127.0.0.1 bağlaması güvenlik önlemidir, konteyner içinde ise erişilemezlik nedenidir. Konteynerin içindeki uygulama tüm arayüzlerde dinlemeli; dışarıya kapatma işi port yayımlama seviyesinde yapılır.

Kontrol listesi

• Uygulama yığınları kullanıcı tanımlı ağlarda (varsayılan bridge kullanılmıyor)
• Konteynerler birbirine servis adıyla erişiyor, IP adresi sabitlenmemiş
• Veritabanı ve iç servisler port yayımlamıyor
• Dışa açılan portlar 127.0.0.1: ile bağlı veya ters vekil arkasında
• Arka uç ağı internal: true ile dış çıkışı kapalı (uygunsa)
• Host modu yalnız gerçekten gerektiğinde ve bilinçli kullanılıyor
• Macvlan kullanılıyorsa IP çakışması ve ana sistem erişimi çözülmüş
• Konteyner içindeki uygulamalar 0.0.0.0 üzerinde dinliyor
• ss -tulpn çıktısındaki her açık port açıklanabiliyor

Ağ katmanı oturduktan sonra sıra dışarı yayımlamada: ters vekil sunucu karşılaştırması. Compose dosyasının üretim ayarları Docker Compose üretim rehberinde, güvenlik sertleştirmesi Docker güvenlik yazısında, verinin kalıcılığı Docker veri kalıcılığı yazısında. Sunucu katmanlarının bütünü Linux sunucu yönetimi yol haritasında.

Konteyner ve fiziksel ağın birlikte tasarlanması gereken kurumsal kurgular için network yönetimi hizmet sayfasına bakabilirsiniz.

Kaynaklar

• Docker Networking overview (ağ sürücüleri ve davranışları)
• Packet filtering and firewalls (port yayımlama ve firewall etkileşimi)
• ip-link(8) manual page (Linux sanal ağ arayüzleri)