WireGuard ile Mesh Ağ Kurulumu

Üç farklı sağlayıcıda beş sunucunuz var ve hepsinin birbiriyle özel adresler üzerinden konuşmasını istiyorsunuz. Klasik çözüm bir merkez sunucu seçip herkesi oraya bağlamaktır, ama bu merkez hem tek arıza noktası olur hem de iki sunucu arasındaki trafiği gereksiz yere bir üçüncü lokasyondan dolaştırır. WireGuard mesh ağ kurulumu bu problemi kökünden çözer: her düğüm diğer her düğümle doğrudan şifreli bir tünel kurar, trafik en kısa yoldan gider ve tek bir düğümün ölmesi kalan bağlantıları etkilemez.

Bu rehberde önce hub-and-spoke ile mesh arasındaki farkı netleştireceğim, sonra kurulumun asıl zor kısmı olan adres ve anahtar planlamasını yapacağız. Ardından üç düğümlü tam bir mesh'i baştan sona kuracağız, NAT arkasındaki düğümlerin nasıl davrandığını göreceğiz ve düğüm sayısı arttıkça ortaya çıkan ölçekleme problemini ele alacağız. Sonunda izleme, anahtar rotasyonu ve sahada en sık gördüğüm yapılandırma hatalarına da değineceğim.

Hub-and-Spoke ile Mesh Arasındaki Fark#

WireGuard'da istemci ve sunucu diye bir ayrım yoktur; her uç birer peer'dir ve kimin kime bağlandığı tamamen yapılandırmayla belirlenir. Bu yüzden aynı yazılımla iki farklı topoloji kurabilirsiniz.

Hub-and-spoke modelinde merkezde bir düğüm bulunur, diğerleri yalnızca onu tanır. A düğümü B'ye paket göndermek istediğinde paket önce merkeze gider, orada yönlendirilir ve B'ye ulaşır. Yapılandırma basittir: her yeni düğüm yalnızca merkeze eklenir. Bedeli ise iki katmanlıdır: merkez düşerse hiçbir düğüm birbirini göremez ve her trafik merkezin bant genişliğini ve gecikmesini üstlenir.

Tam mesh modelinde her düğüm diğer her düğümü tanır. Trafik doğrudan gider, gecikme en düşüktür ve merkez diye bir kavram olmadığı için tek arıza noktası yoktur. Bedeli yapılandırma karmaşıklığıdır: her düğüme, diğer tüm düğümler için birer peer bloğu yazmanız gerekir.

İki lokasyonu birleştiren daha basit senaryoyu daha önce siteden siteye VPN tüneli kurulumu yazısında anlattım; bu rehber onun çok uçlu halidir ve oradaki AllowedIPs mantığı burada da geçerlidir.

Adres Planı ve Anahtar Matrisi#

Mesh kurulumunda hatanın büyük kısmı planlamada yapılır, komutlarda değil. İşe düğüm başına iki bilgiyi sabitleyerek başlayın: tünel adresi ve açık anahtar.

Tünel için ayrı bir aralık ayırın; hiçbir düğümün yerel ağıyla çakışmamalı. 10.99.0.0/24 gibi bir aralık beş yüz düğüme kadar rahatça yeter.

Dikkat edilecek nokta: arayüz adresini /24 maskesiyle vermek, tüm mesh aralığının bu arayüz üzerinden erişilebilir olduğunu sisteme söyler; peer bazındaki AllowedIPs ise hangi adresin hangi tünelden gideceğini belirler. Aralıkları planlarken maske hesabını subnet hesaplayıcı ile doğrulayın; özellikle düğümlerin yerel ağlarını da mesh'e dahil edecekseniz çakışma riski gerçektir.

Anahtarları her düğümde yerel olarak üretin; özel anahtar hiçbir zaman düğümden çıkmamalıdır:

apt install -y wireguard

umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key

# Bu değeri diğer düğümlere dağıtacaksınız
cat /etc/wireguard/public.key

İsteğe bağlı ama tavsiye edilen bir katman daha var: her peer çifti için ortak bir ön paylaşımlı anahtar (PresharedKey) üretmek. Bu, mevcut şifrelemenin üzerine simetrik bir kat daha ekler ve ileride kriptografik varsayımlar zayıflarsa ek koruma sağlar:

# Peer çifti başına bir tane üretilir, her iki tarafın yapılandırmasına yazılır
wg genpsk

Üç Düğümlü Tam Mesh Yapılandırması#

Şimdi tabloyu yapılandırmaya çevirelim. Her düğümde /etc/wireguard/wg0.conf dosyası bir [Interface] bloğu ve diğer her düğüm için bir [Peer] bloğu içerir.

node-a üzerindeki dosya:

[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = NODE_A_OZEL_ANAHTARI

[Peer]
# node-b
PublicKey = NODE_B_ACIK_ANAHTARI
PresharedKey = AB_PAYLASIMLI_ANAHTARI
Endpoint = 185.12.34.56:51820
AllowedIPs = 10.99.0.2/32, 10.30.0.0/24

[Peer]
# node-c (NAT arkasında, Endpoint yok)
PublicKey = NODE_C_ACIK_ANAHTARI
PresharedKey = AC_PAYLASIMLI_ANAHTARI
AllowedIPs = 10.99.0.3/32

node-b üzerindeki dosya:

[Interface]
Address = 10.99.0.2/24
ListenPort = 51820
PrivateKey = NODE_B_OZEL_ANAHTARI

[Peer]
# node-a
PublicKey = NODE_A_ACIK_ANAHTARI
PresharedKey = AB_PAYLASIMLI_ANAHTARI
Endpoint = 185.12.34.10:51820
AllowedIPs = 10.99.0.1/32, 10.20.0.0/24

[Peer]
# node-c
PublicKey = NODE_C_ACIK_ANAHTARI
PresharedKey = BC_PAYLASIMLI_ANAHTARI
AllowedIPs = 10.99.0.3/32

node-c dış dünyadan erişilemediği için her iki komşusuna da Endpoint yazar ve bağlantıyı canlı tutar:

[Interface]
Address = 10.99.0.3/24
ListenPort = 51820
PrivateKey = NODE_C_OZEL_ANAHTARI

[Peer]
PublicKey = NODE_A_ACIK_ANAHTARI
PresharedKey = AC_PAYLASIMLI_ANAHTARI
Endpoint = 185.12.34.10:51820
AllowedIPs = 10.99.0.1/32, 10.20.0.0/24
PersistentKeepalive = 25

[Peer]
PublicKey = NODE_B_ACIK_ANAHTARI
PresharedKey = BC_PAYLASIMLI_ANAHTARI
Endpoint = 185.12.34.56:51820
AllowedIPs = 10.99.0.2/32, 10.30.0.0/24
PersistentKeepalive = 25

Üçünde de tüneli başlatın ve durumu doğrulayın:

systemctl enable --now wg-quick@wg0

# Her peer için son el sıkışma ve aktarılan bayt
wg show

# Karşılıklı erişimi test et
ping -c 3 10.99.0.2
ping -c 3 10.99.0.3

Burada tekrar vurgulamak gerekiyor: AllowedIPs hem yönlendirme tablosu hem erişim listesidir. Aynı arayüzdeki iki farklı peer'e çakışan aralıklar yazarsanız davranış belirsizleşir; WireGuard en uzun eşleşen öneke göre karar verir ve siz hangi tünelden gittiğini takip edemez hale gelirsiniz. Her peer için ayrık aralıklar yazın.

NAT Arkasındaki Düğümler#

Mesh'in en çok soru üreten kısmı budur. Bir düğüm NAT arkasındaysa dışarıdan ona bağlanılamaz; bağlantıyı onun başlatması gerekir. WireGuard bunu doğal olarak destekler: Endpoint bilgisi olmayan bir peer, o peer'den ilk paket geldiğinde adresini öğrenir ve o adresi kullanmaya başlar.

Kritik ayar PersistentKeepalive'dır. NAT cihazları, üzerinden bir süre trafik geçmeyen çeviri girdilerini siler; girdi silinince dışarıdan gelen paketler düşer ve tünel tek yönlü ölür. PersistentKeepalive = 25 her 25 saniyede bir küçük bir paket göndererek girdiyi canlı tutar. Bu değer, tipik NAT zaman aşımlarının altında kalacak şekilde seçilmiştir.

İki düğüm de NAT arkasındaysa doğrudan tünel kurmak zorlaşır; ikisi de karşı tarafın gerçek adresini bilemez. Bu durumda üç seçeneğiniz var: bir tarafta port yönlendirme tanımlamak, ikisinin de ulaşabileceği açık bir düğümü aracı olarak kullanmak (kısmi mesh), ya da otomatik delik açma (NAT traversal) yapan bir katman eklemek. Sonuncusu için hazır çözümlere Tailscale ve Headscale ile özel ağ yazısında değindim; WireGuard'ı temel alıp bu koordinasyon işini otomatikleştirirler.

Ölçeklendirme: Kare Sorunu ve Kısmi Mesh#

Tam mesh matematiksel olarak hızla büyür. Beş düğümde 10 tünel ve düğüm başına 4 peer bloğu vardır; on düğümde 45 tünel ve düğüm başına 9 blok olur. Yirmi düğümde 190 tünel ve elle yönetilemez bir yapılandırma yığını.

Sınırı şöyle koyabilirsiniz: on düğüme kadar elle tam mesh yönetilebilir. Üzerine çıkacaksanız iki yoldan biri gerekir.

Birincisi otomasyon. Yapılandırmayı şablondan üretin; düğüm listesini tek bir veri dosyasında tutup her düğümün dosyasını oradan render edin. Ansible ile sunucu otomasyonu yazısındaki yaklaşım bu iş için birebir uygundur; bir düğüm eklediğinizde tüm düğümlerin yapılandırması yeniden üretilir ve dağıtılır. Yeniden yükleme sırasında mevcut tünelleri düşürmemek için wg-quick down/up yerine şu komutu kullanın:

# Tünelleri düşürmeden yapılandırmayı senkronize et
wg syncconf wg0 <(wg-quick strip wg0)

İkincisi kısmi mesh. Her düğümün her düğümü tanımasına gerek olmayabilir. Sık konuşan düğüm çiftlerini doğrudan bağlayıp, seyrek konuşanları bir aktarma düğümü üzerinden geçirebilirsiniz. Örneğin uygulama ve veritabanı sunucuları doğrudan bağlansın, yedekleme düğümü yalnızca merkez üzerinden erişsin. Bu, gecikmenin önemli olduğu yollarda mesh'in avantajını korurken yapılandırma yükünü ciddi biçimde düşürür.

Yönlendirme, DNS ve Servis Keşfi#

Mesh içindeki adresleri elle yazmak kısa sürede yorucu olur. 10.99.0.2 yerine db.mesh yazabilmek hem betikleri okunur kılar hem de bir düğümün adresi değiştiğinde tek yerde düzenleme yapmanızı sağlar.

En basit yöntem her düğüme aynı /etc/hosts girdilerini dağıtmaktır:

10.99.0.1  node-a app.mesh
10.99.0.2  node-b db.mesh
10.99.0.3  node-c backup.mesh

Düğüm sayısı artınca bu dosyayı senkron tutmak zorlaşır; o noktada mesh içinde küçük bir DNS sunucusu çalıştırmak daha temizdir. Kurulum ayrıntıları için BIND DNS sunucu kurulumu yazısına bakabilirsiniz; mesh için ayrı bir iç bölge tanımlayıp yalnızca tünel arayüzünden dinletmek yeterlidir.

Yerel ağları da mesh'e dahil ediyorsanız yönlendirmeyi açmayı unutmayın ve tünel arayüzünden gelen trafiğe güvenlik duvarında izin verin:

echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/99-mesh.conf
sysctl --system

# Tünel portu ve tünelden gelen trafik
ufw allow 51820/udp
nft add rule inet filter input iifname "wg0" accept

Servislerinizi mümkün olduğunca yalnızca tünel adresinde dinletin. Bir veritabanını 0.0.0.0 yerine 10.99.0.2 üzerinde dinletmek, onu internetten tamamen görünmez kılar ve güvenlik duvarı kuralına bağımlılığı azaltır.

İzleme, Anahtar Rotasyonu ve Güvenlik#

Mesh'in sinsi tarafı, bir tünelin ölmesinin fark edilmemesidir; diğerleri çalıştığı için genel tablo sağlıklı görünür. Bu yüzden peer bazında izleme yapmalısınız. wg show çıktısındaki latest handshake değeri en güvenilir sinyaldir; iki dakikadan eski bir el sıkışma o tünelin sorunlu olduğunu gösterir.

# Peer başına son el sıkışma zaman damgası (unix saniye)
wg show wg0 latest-handshakes

# Aktarılan bayt miktarları
wg show wg0 transfer

Bu çıktıyı basit bir betikle izleme sisteminize besleyebilirsiniz; her peer için "son el sıkışmadan bu yana geçen saniye" metriği, mesh sağlığını tek bakışta gösterir.

Anahtar rotasyonu konusunda gerçekçi olalım: tam mesh'te bir düğümün anahtarını değiştirmek, o düğümü tanıyan tüm düğümlerde güncelleme yapmayı gerektirir. Bu yüzden rotasyonu otomasyonla yapmıyorsanız yılda bir kereden sık planlamayın. Buna karşılık bir düğüm ele geçirildiğinde derhal yapmanız gereken şey nettir: o düğümün peer bloğunu diğer tüm düğümlerden silin. Silinen bir peer'in anahtarı artık kabul edilmez ve düğüm mesh'ten anında düşer.

Bir düğümü kaldırmanın komut karşılığı şudur:

# Belirli bir açık anahtara sahip peer'i çalışırken kaldır
wg set wg0 peer NODE_C_ACIK_ANAHTARI remove

# Kalıcı olması için yapılandırma dosyasından da blok silinmeli

Sık Yapılan Hatalar ve Tuzaklar#

Peer'ler arasında çakışan AllowedIPs. İki farklı peer'e aynı ya da iç içe geçen aralık yazmak, trafiğin hangi tünele gideceğini belirsizleştirir. Her peer için ayrık aralıklar tanımlayın; tünel adreslerini /32 olarak yazmak bu karışıklığı önler.

Arayüz adresini yanlış maskeyle vermek. [Interface] Address alanına /32 yazarsanız mesh'in geri kalanına giden rota oluşmaz. Tüm mesh aralığını kapsayan maskeyi verin.

PersistentKeepalive'ı her yere koymak. NAT arkasında olmayan düğümlerde gereksizdir; sürekli küçük paket üretir ve mobil bağlantılarda pil tüketir. Yalnızca gerçekten NAT arkasındaki düğümlerde kullanın.

Yapılandırma değiştirince tüm tünelleri düşürmek. wg-quick down ve up çifti tüm bağlantıları koparır. wg syncconf ile yalnızca değişen kısmı uygulayın.

MTU'yu görmezden gelmek. WireGuard tünel arayüzü varsayılan olarak 1420 MTU kullanır. Alttaki hat daha düşük MTU'ya sahipse (bazı mobil ve PPPoE bağlantılarında olur) büyük paketler sessizce düşer. Küçük ping çalışıp dosya aktarımı takılıyorsa MTU'yu 1380 civarına indirip test edin.

Özel anahtarları merkezden dağıtmak. Kolay göründüğü için anahtar çiftlerini tek bir makinede üretip dağıtmak yaygın bir hatadır. Özel anahtar üretildiği düğümden çıkmamalı; yalnızca açık anahtarlar dolaşmalıdır.

Sıkça Sorulan Sorular#

WireGuard mesh kaç düğüme kadar ölçeklenir#

Teknik bir sınır yok; sınır yönetilebilirliktedir. Tam mesh'te tünel sayısı düğüm sayısının karesiyle orantılı büyür, bu yüzden elle yönetim yaklaşık on düğüme kadar makul kalır. Üzerine çıkacaksanız ya yapılandırmayı şablondan üreten bir otomasyon kurun ya da kısmi mesh'e geçip yalnızca sık konuşan düğümleri doğrudan bağlayın. Yüzlerce düğüm için koordinasyonu otomatikleştiren bir katman kullanmak daha sağlıklıdır.

AllowedIPs tam olarak ne yapıyor#

İki iş birden yapar ve bu yüzden en çok yanlış anlaşılan ayardır. Giden yönde bir yönlendirme tablosudur: bu aralıklara giden paketler ilgili peer'in tüneline sokulur. Gelen yönde ise bir erişim listesidir: o peer'den yalnızca bu aralıklardaki kaynak adreslerle gelen paketler kabul edilir, diğerleri düşürülür. Bir ağı buraya yazmadıysanız o ağa ne paket gider ne de oradan paket kabul edilir.

Bir düğüm çökerse mesh çalışmaya devam eder mi#

Evet, tam mesh'in asıl kazancı budur. Her tünel bağımsızdır; bir düğüm kapandığında yalnızca ona giden tüneller etkilenir, diğer düğümler birbirini görmeye devam eder. Hub-and-spoke modelinde ise merkezin düşmesi tüm iletişimi durdurur. Kısmi mesh kullanıyorsanız, aktarma görevi verdiğiniz düğümlerin yedeğini düşünmeniz gerekir.

NAT arkasındaki iki düğüm doğrudan konuşabilir mi#

Saf WireGuard ile genellikle hayır, çünkü ikisi de karşı tarafın gerçek dış adresini ve portunu bilemez. Çözüm için üç yol var: bir tarafta port yönlendirme tanımlamak, ikisinin de ulaşabildiği açık bir düğümü aracı yapmak, ya da NAT delik açma işlemini otomatikleştiren bir koordinasyon katmanı kullanmak. Üçüncü seçenek büyük ölçekte en pratik olanıdır ve WireGuard'ı temel alan hazır çözümler bu işi yapar.

WireGuard trafiği güvenlik duvarında nasıl görünür#

Tek bir UDP akışı olarak görünür; varsayılan port 51820'dir ama istediğiniz portu seçebilirsiniz. İçerideki protokol, hedef adres ve içerik tamamen şifrelidir, dolayısıyla derin paket incelemesi yapan bir cihaz tünelin içini göremez. Kısıtlayıcı ağlarda UDP tamamen engellenmişse WireGuard çalışmaz; böyle bir ortamda TCP üzerinden çalışabilen bir alternatife ya da bir sarmalayıcıya ihtiyaç duyarsınız.

Mesh içindeki sunucular internete de bu tünelden çıkabilir mi#

Çıkabilir ama bu ayrı bir karardır. Bir peer'in AllowedIPs değerini 0.0.0.0/0 yaparsanız tüm trafik o tünele yönlenir; bu, bir düğümü çıkış ağ geçidi haline getirmek demektir. Mesh senaryosunda genellikle istenen bu değildir, çünkü tüm internet trafiğini tek bir düğüm üzerinden geçirmek hem gecikme ekler hem de o düğümü darboğaz yapar. Yalnızca özel adres aralıklarını tünele yönlendirmek çoğu kurulum için doğru tercihtir.

Kapanış#

WireGuard mesh, sunucular arasında düşük gecikmeli ve merkezsiz bir özel ağ kurmanın en sade yolu. Aklınızda kalması gereken dört alışkanlık şu: adres planını kurulumdan önce tabloya dökün ve çakışma olmadığını doğrulayın; her peer için ayrık AllowedIPs yazın ve bunun hem rota hem erişim listesi olduğunu unutmayın; PersistentKeepalive ayarını yalnızca NAT arkasındaki düğümlerde kullanın; ve yapılandırmayı değiştirirken tünelleri düşürmemek için wg syncconf tercih edin. Düğüm sayısı ona yaklaştığında elle yönetimi bırakıp şablon üretimine geçin.

Mesh'in en az bir açık ucu olması işleri çok kolaylaştırır; sabit IP'li VDS ve bulut sunucu paketlerimiz bu rolü üstlenebilir, kendi ağ topolojiniz üzerinde tam kontrol istiyorsanız dedicated sunucu tarafına bakabilirsiniz. Mesh planını, anahtar dağıtımını ve izleme kurulumunu sizin yerinize yapmamızı isterseniz sunucu yönetimi hizmetimiz bu işi üstlenir.