Ubuntu Network Konfigürasyon Dosyası ve Ağ Ayarları

Ubuntu Neden Netplan'a Geçti?

Ubuntu 18.04 LTS itibarıyla geleneksel ifupdown araç seti —yani /etc/network/interfaces dosyası ve ifup / ifdown komutları— yerini Netplan'a bıraktı. Bu karar sizi ilk gördüğünüzde biraz şaşırtabilir: "Yıllarca çalışan bir şeyi neden değiştirdiler?" Gerekçe, Ubuntu'nun hem masaüstü hem de sunucu ekosistemini tek bir katman altında yönetebilme ihtiyacıdır.

Netplan, "frontend" konumundadır; yani siz YAML dosyasına ne yazarsanız Netplan bunu arka plandaki gerçek ağ yöneticisine —sunucularda systemd-networkd, masaüstünde NetworkManager— devreder. Bu iki katlı mimari ilk başta karmaşık görünse de sunucu bakımını kolaylaştırır: bir kez öğrenilmiş YAML sözdizimi, hangi Ubuntu sürümünü kullanırsanız kullanın aynı şekilde çalışır.

Ubuntu 24.04 LTS ve üzerinde ifupdown paketi kurulu bile gelmez; dolayısıyla eski yönteme dönme lüksünüz yoktur. Netplan'ı erken öğrenmek en verimli yaklaşımdır.

Netplan'ın önemli bir avantajı, yapılandırma değişikliklerinin kalıcı olmasıdır. ifupdown döneminde bazı yöneticiler ip addr add ile elle IP ekler ve yeniden başlatma sonrasında bu ayarların kaybolduğunu unuturdu. Netplan ile /etc/netplan/ altındaki YAML dosyası sistem her başladığında okunduğundan, yaptığınız değişiklikler kalıcı olarak uygulanır.

/etc/netplan/ Dizin Yapısı ve Dosya Öncelik Sırası

Tüm Netplan yapılandırmaları /etc/netplan/ dizininde YAML uzantılı dosyalar olarak saklanır. Dizinde birden fazla dosya bulunabilir; Netplan bunları sayısal önek sırasına göre okur ve birleştirir:

/etc/netplan/
├── 00-installer-config.yaml   # Ubuntu Server kurulumcusu oluşturur
├── 01-netcfg.yaml             # Elle oluşturduğunuz ek yapılandırmalar
└── 99-cloud-init.yaml         # Cloud-init tarafından üretilen (VPS/cloud ortam)

Küçük ama kritik not: aynı anahtar iki dosyada tanımlıysa küçük sayı öncelik kazanır. Örneğin 00-installer-config.yaml içinde ens3 için DHCP tanımlıysa ve siz 01-netcfg.yaml içinde aynı arayüzü statik IP ile yapılandırmaya çalışırsanız, 00 kazanır. Elinizde bulut ortamında üretilmiş 99-cloud-init.yaml varsa ve onu devre dışı bırakmak istiyorsanız:

# cloud-init ağ yönetimini devre dışı bırak
sudo bash -c 'echo "network: {config: disabled}" > /etc/cloud/cloud.cfg.d/99-disable-network.cfg'

Bu komuttan sonra cloud-init bir sonraki yeniden başlatmada 99-cloud-init.yaml üretmez; sizin elle yazdığınız dosya tek kaynak olur.

Buyukweb VDS'lerinde genellikle kurulumun ardından /etc/netplan/ altında tek bir dosya gelir. Bu dosyayı doğrudan düzenleyebilir ya da yeni bir önekli dosya oluşturabilirsiniz.

Renderer: networkd mi, NetworkManager mı?

Netplan yapılandırma dosyasının tepesindeki renderer anahtarı, YAML'ın hangi arka plana gönderileceğini belirler:

Renderer	Ne zaman kullanılır?
networkd	Sunucular (Ubuntu Server, headless sistemler, VDS)
NetworkManager	Masaüstü sistemler (GNOME/KDE bağlantı yöneticisi)

Sunucu ortamında her zaman renderer: networkd tercih edin. NetworkManager masaüstü GUI'sinin ve nmcli aracının arka planıdır; sunucuda gereksiz bağımlılık ekler.

systemd-networkd servis olarak çalışır; durumunu şununla görebilirsiniz:

sudo systemctl status systemd-networkd

Eğer inactive görüyorsanız sudo systemctl enable --now systemd-networkd ile etkinleştirin.

Renderer belirtmezseniz Netplan varsayılan olarak networkd kullanır (Ubuntu Server kurulumlarında). Ancak her iki renderer birlikte çalışmamalıdır; aynı sisteme hem systemd-networkd hem NetworkManager renderer atıyorsanız çakışma yaşanır. Ubuntu Desktop ISO'su ile kurulmuş bir makinede renderer: networkd yazmanız durumunda NetworkManager aktif olabileceğinden, sudo systemctl disable NetworkManager ile önce onu devre dışı bırakın.

Statik IP Yapılandırması

Sunucularda statik IP zorunludur; DHCP ile değişen bir IP, DNS kayıtlarını ve SSH erişimini bozar. Ayrıca web sunucusu, posta sunucusu veya veritabanı gibi servisleri çalıştırıyorsanız, IP adresinizin değişmesi bu servislere olan bağlantıyı anında koparır. Buyukweb VDS paneli üzerinden size atanan IP adresini not alın; aşağıdaki örnekteki 185.100.200.50 yerine kendi IP'nizi yazın.

Aşağıda tam bir üretim yapılandırması:

# /etc/netplan/01-static.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: false
      dhcp6: false
      addresses:
        - 185.100.200.50/24
      routes:
        - to: default
          via: 185.100.200.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8
        search:
          - sirketiniz.com

YAML girinti uyarısı: Netplan kesinlikle 2 boşluk girintisi kullanır. 4 boşluk veya sekme (tab) hataya yol açar. Bu, en sık düşülen tuzaktır.

Değişikliği uygulamadan önce test edin:

sudo netplan try

netplan try yapılandırmayı geçici olarak uygular ve 120 saniye bekler. Terminal oturumunda onaylamazsanız eski ayarlara döner. Bu özellik SSH bağlantınızın kesilmesini önleyen en önemli güvenlik ağıdır.

Yapılandırma sorunsuzsa kalıcı hale getirin:

sudo netplan apply

Sözdizimi hatası var mı diye önceden bakabilirsiniz:

sudo netplan --debug generate

DNS Resolver: systemd-resolved ve /etc/resolv.conf Symlink Uyarısı

Ubuntu'da DNS çözümlemesi systemd-resolved servisi üzerinden gerçekleşir. Bu servis 127.0.0.53 adresinde bir stub resolver çalıştırır; uygulamalar DNS sorgularını oraya gönderir. systemd-resolved aynı zamanda DNSSEC doğrulama ve DNS-over-TLS (DoT) desteği sunduğundan, DNS güvenliği açısından da /etc/resolv.conf içine elle nameserver yazmaktan üstündür.

/etc/resolv.conf dosyasına bakarsanız genellikle bir sembolik bağlantı (symlink) olduğunu görürsünüz:

ls -la /etc/resolv.conf
# lrwxrwxrwx 1 root root 39 ... /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Bu dosyayı doğrudan düzenlemeyin; netplan apply sonrasında üzerine yazılır. DNS sunucularınızı Netplan YAML'ının nameservers.addresses bloğuna yazın (yukarıdaki örneğe bakın).

Mevcut DNS çözümlemesini görmek için:

resolvectl status

Belirli bir domain için hangi DNS sunucusunun kullanıldığını sorgulayabilirsiniz:

resolvectl query buyukweb.com

Eğer /etc/resolv.conf symlink değilse ve bozulmuşsa:

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved

Bridge Yapılandırması (KVM Sanal Makineleri İçin)

Bridge ağ arayüzü, bir sanal makinenin fiziksel ağda birinci sınıf bir katılımcı gibi görünmesini sağlar. Başka bir deyişle, sanal makine kendi MAC adresiyle doğrudan switch'e bağlıymış gibi davranır; NAT gerektirmez ve dış dünyadan direkt ulaşılabilir olur. Buyukweb VDS'leri KVM hipervizörü üzerinde çalışır; kendi içinizde bir sanal makine oluşturuyorsanız (iç içe KVM senaryosu veya libvirt) bridge yapılandırması gerekir.

Bridge oluşturmadan önce bridge-utils paketini kurmanız gerekmeyebilir; systemd-networkd kendi kendine bridge yönetimi yapabilir. Ancak bridge hata ayıklaması için brctl show veya ip link show type bridge komutları kullanışlıdır.

# /etc/netplan/01-bridge.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: false
  bridges:
    br0:
      interfaces:
        - ens3
      dhcp4: false
      addresses:
        - 185.100.200.50/24
      routes:
        - to: default
          via: 185.100.200.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8
      parameters:
        stp: false
        forward-delay: 0

stp: false ve forward-delay: 0 sunucu ortamında önerilir; STP (Spanning Tree Protocol) gereksiz gecikme ekler, tek switch yapısında kapalı tutun.

VLAN Yapılandırması (802.1Q Tagged Interface)

VLAN (Virtual LAN), aynı fiziksel ağ altyapısında mantıksal olarak birbirinden izole edilmiş ağ segmentleri oluşturmanızı sağlar. 802.1Q standardına göre, her frame'e bir VLAN ID (1-4094 arası) etiketi eklenir; switch bu etikete bakarak frame'i doğru VLAN'a iletir.

Eğer veri merkeziniz VLAN trunk bağlantısı sunuyorsa (bazı kurumsal senaryolarda özel VLAN talep edilebilir), 802.1Q tagged arayüzü şöyle tanımlarsınız:

# /etc/netplan/01-vlan.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: false
  vlans:
    ens3.100:
      id: 100
      link: ens3
      addresses:
        - 10.10.100.5/24
    ens3.200:
      id: 200
      link: ens3
      addresses:
        - 10.10.200.5/24

Her VLAN arayüzü (ens3.100, ens3.200) ayrı bir IP ve yönlendirme tablosu alır. Çok kiracılı ortamlar, yönetim/üretim ağ ayrımı veya depolama ağı izolasyonu için yaygın bir yapıdır.

Çoklu Arayüz: Public + Private Network

Buyukweb VDS'lerde çift NIC senaryosu mümkündür: ens3 public IP alırken ens4 özel ağ (private VLAN) üzerinden sunucu-sunucu iletişimi sağlar. Bu mimaride dış trafik public arayüzden, iç veritabanı/depolama trafiği private arayüzden geçer.

Bu yapının pratik faydası büyüktür: örneğin bir web sunucusu ile veritabanı sunucusu arasındaki trafik private ağdan geçtiğinde hem gecikme düşer (veri merkezi içi bağlantı) hem de veritabanı portları dış dünyaya açılmaz. Güvenlik açısından public arayüze sadece 80, 443 ve 22 portlarını açmak yeterli; 3306 (MySQL) veya 5432 (PostgreSQL) portları yalnızca private interface üzerinden erişilebilir olur.

# /etc/netplan/01-dual-nic.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: false
      addresses:
        - 185.100.200.50/24
      routes:
        - to: default
          via: 185.100.200.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8
    ens4:
      dhcp4: false
      addresses:
        - 10.0.0.10/24
      # Private ağa default route EKLEME; sadece iç ağa rota ver
      routes:
        - to: 10.0.0.0/8
          via: 10.0.0.1

Önemli: private arayüze to: default rotası eklemeyin. İki default route asimetrik routing sorununa yol açar ve TCP oturumları beklenmedik yollardan çıkabilir.

WireGuard ve Network Namespace'e Kısa Değinme

WireGuard, modern ve yüksek performanslı bir VPN protokolüdür. OpenVPN veya IPSec'e kıyasla çok daha küçük bir kod tabanına sahiptir (yaklaşık 4.000 satır kernel kodu) ve bu sadelik güvenlik denetimini kolaylaştırır. Sunucular arası şifreli tünel kurmak, uzak ofis bağlantısı veya site-to-site VPN için tercih edilen bir çözümdür.

Ubuntu 20.04 ve üzerinde WireGuard kernel modülü doğrudan desteklenir (apt install wireguard). Netplan, WireGuard tünellerini de yönetebilir:

# /etc/netplan/99-wireguard.yaml
network:
  version: 2
  tunnels:
    wg0:
      mode: wireguard
      addresses:
        - 10.200.0.1/24
      private-key: /etc/wireguard/private.key
      peers:
        - public-key: <karşı-taraf-public-key>
          allowed-ips:
            - 10.200.0.2/32
          endpoint: 203.0.113.10:51820

WireGuard yapılandırmasında özel anahtar dosyasını (private.key) chmod 600 ile koruduğunuzdan emin olun; Netplan dosyayı okumak için root yetkisine ihtiyaç duyar.

Network namespace konusu —tek sunucuda birbirinden tamamen izole ağ yığınları oluşturma— daha ileri bir konudur ve genellikle container/VM yönetimi bağlamında çıkar. ip netns komutuyla keşfedebilirsiniz; bu yazının kapsamı dışındadır.

Troubleshooting: Hangi Komutu Ne Zaman Kullanırsınız?

Ağ sorunu yaşadığınızda paniklemek yerine sistematik bir sıra izleyin. Çoğu ağ sorunları üç kategoriden birine girer: (1) IP adresi yanlış veya atanmamış, (2) yönlendirme tablosu bozuk, (3) DNS çözümlenemiyor. Aşağıdaki akış bu üç kategoriyi sırasıyla kontrol eder:

1. Arayüzlerin durumunu görün:

ip addr show
# ya da kısaca:
ip a

Arayüz UP mu, DOWN mu? IP adresi atanmış mı? NO-CARRIER görüyorsanız fiziksel/sanal kablo sorunu var demektir.

2. Yönlendirme tablosunu kontrol edin:

ip route show
# ya da:
ip r

Default gateway var mı? Doğru arayüzden mi çıkıyor? Çıktıda default via 185.100.200.1 dev ens3 satırını görmek istersiniz.

3. Hangi servisler hangi portu dinliyor:

ss -tlnp

ss komutu eski netstat'ın yerine geçmiştir. -t TCP, -l listening, -n sayısal port, -p process gösterir.

4. systemd-networkd günlüklerini inceleyin:

journalctl -u systemd-networkd -n 50 --no-pager

Arayüz için "Configuring network interface" ve "Link UP" satırlarını arıyorsunuz. Hata varsa burada net biçimde yazılır.

5. DNS çözümlemesini test edin:

resolvectl status
resolvectl query google.com

Eğer resolvectl yoksa (Ubuntu 18.04): systemd-resolve --status

6. Temel bağlantı kontrolü:

ping -c 4 1.1.1.1      # IP seviyesi bağlantı
ping -c 4 google.com   # DNS çözümleme + bağlantı
traceroute 8.8.8.8     # Yol analizi

Yaygın Hatalar ve Çözümleri

Netplan ile çalışmaya başlayan sistem yöneticilerinin büyük çoğunluğu aynı birkaç hatayı tekrar tekrar yapar. Bu hataları bir kez öğrenirseniz saatlerce harcayacağınız hata ayıklama süresini dakikalara indirebilirsiniz.

YAML Girinti Hatası (En Sık Karşılaşılan)

Netplan YAML'ı ayrıştırırken çok katıdır. 4 boşluk, sekme veya karışık girinti doğrudan hata verir:

Error in network definition: invalid YAML: inconsistent indentation

Çözüm: Her seviye için tam olarak 2 boşluk kullanın. Düzenleyicinizi expandtab ve shiftwidth=2 ile yapılandırın.

Eski gateway4 Anahtarı

Ubuntu 22.04 itibarıyla gateway4 ve gateway6 anahtarları deprecated (kullanımdan kalkmış) olarak işaretlenmiştir. Kullandığınızda şu uyarıyı alırsınız:

gateway4 has been deprecated, use default routes instead

Doğru kullanım:

routes:
  - to: default
    via: 185.100.200.1

Arayüz İsmi Değişikliği

eth0, eth1 gibi eski isimler artık kullanılmıyor; modern Ubuntu'da ens3, ens4, enp2s0 gibi öngörülebilir (predictable) isimler kullanılıyor. Doğru arayüz ismini öğrenmek için:

ip link show

Birden Fazla Default Gateway

İki arayüze birden to: default rotası eklediğinizde yönlendirme çakışması olur. Yalnızca bir default gateway olmalıdır; diğer arayüzler için spesifik subnet rotaları tanımlayın.

Dosya İzinleri

/etc/netplan/ dosyaları root sahipliğinde ve 600 (ya da 640) izniyle olmalıdır. Farklı bir izin Netplan'ın yapılandırmayı okumamasına neden olabilir:

sudo chmod 600 /etc/netplan/*.yaml
sudo chown root:root /etc/netplan/*.yaml

Buyukweb VDS'de Ağ Yapılandırması: KVM Konsol Avantajı

VDS üzerinde çalışırken en büyük risk şudur: yanlış bir netplan apply SSH bağlantısını keser ve sunucuya ulaşamazsınız. Bu senaryo birçok yöneticinin kâbusu olmuştur.

Buyukweb VDS sunucu paketleri KVM hipervizörü üzerine kuruludur; müşteri panelinden KVM web konsol erişimi mevcuttur. SSH kesilse bile bu konsol aracılığıyla sunucuya bağlanabilir, yanlış yapılandırmayı geri alabilir ve ağı kurtarabilirsiniz.

Pratik kurtarma akışı:

1. Buyukweb müşteri panelinden KVM konsola bağlanın.
2. Yanlış Netplan dosyasını düzeltin veya yedekten geri yükleyin.
3. sudo netplan apply çalıştırın.
4. SSH bağlantısını test edin, konsolu kapatın.

Bu yüzden ağ yapılandırması değişikliği yapmadan önce mevcut dosyayı yedeklemek iyi bir alışkanlıktır:

sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak

netplan try komutunu kullanmayı alışkanlık edinirseniz otomatik geri alma mekanizması sizi korur. Buyukweb VDS'leri Bursa Tier 3 veri merkezinde fiziksel altyapı Türkiye'de olduğundan, teknik destek ekibine ulaşmak ve müdahale süresi açısından avantajlı bir konumdadır.

VDS planlarını incelemek veya ağ yapılandırmasında yardım almak için destek sayfamızı ziyaret edebilirsiniz.

Sık Sorulan Sorular

Ubuntu 22.04'te /etc/network/interfaces dosyası çalışıyor mu?

Çalışabilir, ancak ifupdown paketini ayrıca kurmanız gerekir (sudo apt install ifupdown). Önerilmez; Netplan ile çakışma riski taşır ve modern Ubuntu'nun resmi yöntemi değildir. Üretim sunucularında Netplan kullanın.

netplan try ile netplan apply farkı nedir?

netplan try, yapılandırmayı geçici olarak uygular ve 120 saniye içinde onaylamazsanız (Enter tuşu) önceki ayarlara döner. netplan apply ise doğrudan kalıcı uygular. SSH ile çalışıyorsanız her zaman netplan try ile başlayın.

Birden fazla .yaml dosyası olduğunda hangisi geçerli?

Netplan tüm dosyaları sayısal sıraya göre okuyup birleştirir. Düşük önek numarası önceliklidir; 00-x dosyası, 99-x dosyasındaki aynı anahtar değerini ezer. Aynı arayüzü birden fazla dosyada tanımlamaktan kaçının.

DHCP mi, statik IP mi seçmeliyim?

Sunucularda her zaman statik IP kullanın. DHCP kiralama süresi dolduğunda veya DHCP sunucusu değiştiğinde IP adresi değişebilir; bu DNS kayıtlarını bozar, SSL sertifikalarını etkileyebilir ve servisler erişilemez hale gelebilir. Buyukweb VDS'lerinde panel üzerinden size atanan IP'yi statik olarak yapılandırın.

systemd-resolved'u devre dışı bırakabilir miyim?

Bırakabilirsiniz (sudo systemctl disable --now systemd-resolved) ancak önerilmez. Devre dışı bırakırsanız /etc/resolv.conf'u elle yönetmeniz gerekir. Stub resolver 127.0.0.53 üzerinden sağlanan cache ve DNSSEC desteğini kaybedersiniz.

Netplan hangi Ubuntu sürümünden itibaren varsayılan?

Ubuntu 17.10'dan itibaren dahil edilmiştir; Ubuntu 18.04 LTS ile varsayılan hale geldi. Ubuntu 24.04 LTS'te ifupdown paketi yüklü bile gelmez.

Bridge yapılandırmasında fiziksel arayüze IP adresi atamalı mıyım?

Hayır. Bridge (br0) IP alırken fiziksel arayüz (ens3) yalnızca köprünün bir üyesi olarak tanımlanır; kendine IP atanmaz. Fiziksel arayüze de IP atarsanız yönlendirme karışıklığı yaşarsınız.

Sonuç

Ubuntu'da ağ yapılandırması, Netplan ile birlikte hem daha tutarlı hem de daha ifade edici hale geldi. /etc/netplan/ altındaki YAML dosyası bir kez doğru yazıldığında sistem yeniden başlasa bile ayarlar korunur; systemd-networkd arka planda sessizce çalışır.

Bu yazıda ele aldığımız konular şunlardı: Netplan'ın neden geldiği ve ifupdown'ın ne olduğu, dizin yapısı ve dosya öncelik sırası, renderer seçimi (networkd vs NetworkManager), statik IP yapılandırması ve netplan try güvenlik ağı, DNS resolver'ın nasıl çalıştığı ve /etc/resolv.conf symlink tuzağı, bridge ve VLAN yapılandırması, çoklu NIC senaryosu, WireGuard tünel tanımı ve son olarak sistematik troubleshooting akışı.

Temel akışı hatırlamanız yeterlidir: YAML dosyasını düzenle → sudo netplan try ile test et → onaylarsan sudo netplan apply ile kalıcılaştır. Sorun çıkarsa journalctl -u systemd-networkd ve resolvectl status sizi doğru yöne yönlendirir.

Buyukweb VDS sunucu paketleri Ubuntu 20.04/22.04/24.04 LTS seçeneği sunar; KVM web konsol erişimi sayesinde ağ yapılandırma hatalarında bile sunucunuzu kurtarabilirsiniz. Daha fazla bilgi için destek sayfamızı ziyaret edin.

---

İlgili Hizmetler:

• Linux Hosting
• VDS Sunucu
• Fiziksel Dedicated Sunucu