WireGuard cryptokey routing nasıl çalışır?

WireGuard'ın çalışma mantığı, tek bir fikirle

WireGuard, her paketi bir public key ile ilişkilendirerek çalışır. Bu mekanizmanın adı cryptokey routing'dir ve tüm tasarım bundan ibarettir: bir peer yanındaki AllowedIPs satırı, makinenizden çıkan paketler için yönlendirme tablosu, o peer'dan gelen paketler için ise erişim denetim listesidir. Tek bir ayar, iki farklı işlev. AllowedIPs dosyasını bu bakış açısıyla okuduğunuzda, her WireGuard yapılandırma dosyası anlaşılır hale gelir.

IP adresi ile anahtarlanmış bir oturum tablosu veya kullanıcı veritabanı yoktur. Bir peer, bir public key ve o anahtarın kullanabileceği adresler kümesinden oluşur. El sıkışma (handshake) ve zamanlayıcılar, alttaki ağ değişse bile bu bağın geçerli kalmasını sağlar. Teoriden önce çalışan bir tünel kurmak isterseniz, kendi VPS'iniz üzerinde self-hosted WireGuard VPN oluşturun ve bir yapılandırma satırı sizi şaşırttığında buraya geri dönün.

AllowedIPs bir yönlendirme tablosu ve erişim listesidir

Önce giden trafiği ele alalım. Çekirdeğiniz bir paketi, ana yönlendirme tablosu üzerinden her zamanki gibi wg0 cihazına yönlendirir. WireGuard, paketin hedef adresini, her eşin izin verilen öneklerini tutan bir tabloda, en uzun önek eşleşmesi kuralına göre karşılaştırır. Bir eşleşme, bir eşi; o eş bir genel anahtarı; o anahtar da bir oturum anahtarını ve bir UDP uç noktasını belirler. Paket, ilgili eş için şifrelenir ve oraya gönderilir.

Eğer hiçbir eşin AllowedIPs değeri hedefi kapsamıyorsa, paket gönderilmez; çünkü gönderim için gerekli bir anahtar bulunmamaktadır.

ping: sendmsg: Required key not available

Bu hata tek bir anlama gelir: ulaşmaya çalıştığınız adres hiçbir eşin altında listelenmemiştir. Farklı bir hata olan ping: sendmsg: Destination address required ise, bir eşin eşleştiğini ancak WireGuard'ın onun için bir uç nokta bilgisine sahip olmadığını gösterir; çünkü ne bir yapılandırma yapılmış ne de henüz bir bilgi öğrenilmiştir.

Şimdi gelen trafiği ele alalım. Bir UDP paketi dinleme portuna ulaşır. WireGuard, başlık kısmındaki alıcı indeksinden oturumu bulur, sayacı kayan bir tekrar oynatma penceresine (sliding replay window) karşı kontrol eder, ardından yükün şifresini çözer ve doğrular. Ancak bundan sonra iç paketi okur ve bu iç paketin kaynak adresi, gönderen eşin AllowedIPs değerinin içinde yer almalıdır. Eğer yer almıyorsa, paket düşürülür. Dinamik hata ayıklama (dynamic debug) etkinleştirildiğinde, çekirdek nedeni şu satıra benzer bir şekilde yazdırır:

wg0: Packet has unallowed src IP (10.8.0.9) from peer 2 (203.0.113.10:51820)

Sunucu tarafındaki bir eşin /32 almasının nedeni budur. AllowedIPs = 10.8.0.2/32 ile yapılandırılmış bir eş, yalnızca 10.8.0.2 adresinden paket gönderebilir, başka hiçbir adresten gönderemez. Oraya 0.0.0.0/0 yazarsanız, bu istemcinin tüneliniz içindeki başka bir istemcinin adresi de dahil olmak üzere herhangi bir kaynak adresini kullanarak paket enjekte etmesine izin vermiş olursunuz.

Örtüşen önekler, arama işlemi en uzun önek eşleşmesi (longest prefix match) prensibiyle çalıştığı için özgüllük sırasına göre çözümlenir. İki eş üzerinde aynı öneklerin bulunması farklı sonuçlar doğurur: giriş, en son yapılandırılan eşe taşınır ve ilk eş, hiçbir hata mesajı üretilmeksizin o trafiği almayı durdurur. wg show wg0 allowed-ips, diskteki dosya ile çalışan durum birbirinden koptuğunda esas alınması gereken, çekirdekteki güncel tabloyu yazdırır.

Cryptokey yönlendirmesi dikkate alınarak bir yapılandırma dosyasının okunması

Sunucu tarafı:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <server private key>

[Peer]
PublicKey = <laptop public key>
AllowedIPs = 10.8.0.2/32

İstemci tarafı:

[Interface]
Address = 10.8.0.2/32
PrivateKey = <laptop private key>

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Aynı anahtar kelime, iki tarafta da zıt ağırlığa sahiptir. İstemci tarafında bu, "her hedefi bu eşe gönder" anlamına gelir. Sunucu tarafında ise "bu eşten yalnızca bu adresi kabul et" anlamına gelir. Asimetri, rollerde değil değerlerde bulunur.

Bu anahtarların yarısı aslında protokole ait değildir. Address, DNS, MTU, PostUp ve SaveConfig, arayüzü ayağa kaldıran kabuk betiği olan wg-quick'e aittir. Çekirdek bunları asla görmez. wg-quick strip wg0, wg aracının fiilen yüklediği indirgenmiş yapılandırmayı yazdırır; bu ayrımı görmenin en hızlı yolu budur.

El sıkışma süreci gerçekte ne yapar

WireGuard el sıkışması, Noise Protocol Framework içerisinden Noise_IKpsk2 protokolünü kullanır. IK kısmı, bir sistem yöneticisi için işlevsel olan bölümdür: Yanıtlayıcının statik genel anahtarı, [Peer] bloğunuzdaki PublicKey olduğu için başlatıcı tarafından zaten bilinmektedir ve başlatıcı, kendi statik genel anahtarını ilk mesajın içinde şifreli olarak gönderir. Bu nedenle sertifika değişimi veya kimlik doğrulaması için ek bir gidiş-dönüş süreci gerekmez. Pasif bir gözlemci, yanıtlayıcının özel anahtarına sahip olmadığı sürece hangi anahtarın çağrı yaptığını tespit edemez.

Bunun maliyeti bir gidiş-dönüş süresidir. Başlatma mesajı 148 bayt, yanıt ise 92 bayttır ve veri akışı hemen ardından başlar. Her iki taraf da her el sıkışma için yeni bir geçici Curve25519 anahtar çifti oluşturur ve oturum anahtarları, statik ve geçici anahtarları harmanlayan bir Diffie-Hellman sonuçları zincirinden türetilir. Geçici özel anahtarlar daha sonra silinir; bu da ileriye dönük gizlilik (forward secrecy) sağlar: Bugün trafiğinizi kaydeden ve gelecek yıl sunucunun özel anahtarını çalan biri, kaydettiklerini yine de okuyamaz.

Bir el sıkışma başlatma mesajı TAI64N zaman damgası taşır ve her eş, diğerinden gördüğü en büyük zaman damgasını hatırlar; bu sayede yeniden oynatılan (replay) başlatma mesajları reddedilir. Veri paketleri, nonce olarak kullanılan 64-bitlik bir sayaç taşır ve alıcı, yakın zamanda görülen sayaçların kayan bir penceresini tutar. Böylece TCP tarzı bir bağlantı durumuna gerek kalmadan yeniden oynatma ve yoğun paket sıralaması bozuklukları yönetilir.

Oturum anahtarları uzun süre geçerli kalmaz ve zamanlayıcılar yapılandırılabilir değil, derleme aşamasında sabitlenmiştir.

[
  {
    "label": "REKEY_TIMEOUT",
    "seconds": 5,
    "notes": "resend a handshake initiation that got no answer"
  },
  {
    "label": "KEEPALIVE_TIMEOUT",
    "seconds": 10,
    "notes": "send a keepalive after receiving data and sending none back"
  },
  {
    "label": "REKEY_ATTEMPT_TIME",
    "seconds": 90,
    "notes": "give up on the handshake and report the peer as down"
  },
  {
    "label": "REKEY_AFTER_TIME",
    "seconds": 120,
    "notes": "sender begins a fresh handshake for a new session key"
  },
  {
    "label": "REJECT_AFTER_TIME",
    "seconds": 180,
    "notes": "the old session key is refused and traffic stops"
  }
]

Bunlar ölçüm değil, protokol spesifikasyonundaki sabit değerlerdir. Bunların 5 tanesi tüm oturum yaşam döngüsünü yönetir. 120 saniyelik kullanımdan sonra gönderici yeni bir el sıkışma başlatır ve 180 saniye sonra eski anahtar tamamen reddedilir; bu nedenle yeni bir el sıkışma tamamlanana kadar trafik durur. Yanıt alınamayan bir başlatma mesajı her 5 saniyede bir yeniden gönderilir ve 90 saniye sonra terk edilir. wg show komutunun latest handshake çıktısını göreceli bir yaş olarak vermesinin ve yoğun, sağlıklı bir tünelin bu yaşı neden küçük tuttuğunun sebebi budur. Aktif olarak trafik gönderdiğiniz halde artan bir yaş, tünelin boşta olduğu anlamına değil, el sıkışmaların başarısız olduğu anlamına gelir.

Neden bir eşin istemci veya sunucu rolü yoktur

Her iki uç da aynı kodu ve aynı yapılandırma biçimini çalıştırır. Sunucu modu yoktur. Hissettiğiniz asimetri Endpoint öğesinden kaynaklanır ve Endpoint isteğe bağlıdır.

Yapılandırılmış bir uç noktaya sahip olan eş, bir el sıkışma başlatabilir. Uç noktası olmayan eş ise bekler; ardından karşı tarafın adresini ve portunu, doğru şekilde kimlik doğrulaması yapılan ilk paketten öğrenir. Öğrenilen bu uç nokta saklanır ve geçerli bir paket yeni bir adresten geldiğinde güncellenir. Dolaşım (roaming) bu şekilde çalışır: Wi-Fi ağından mobil ağa geçen bir dizüstü bilgisayar aynı tüneli korumaya devam eder, çünkü oturum IP adresinden ziyade anahtar ve dizin ile tanımlanır. Hiçbir şey yeniden bağlanmaz, çünkü TCP anlamında hiçbir şey hiçbir zaman "bağlı" olmamıştır.

Aynı mekanizma, bilinmesi gereken bir gerçeği ortaya çıkarır: Genel IP adresine sahip olan eş, her zaman karşı tarafın bilinen son genel IP adresini tutar ve wg show bunu yazdırır.

Sabit ilkeller ve müzakere edilecek bir şey yok

WireGuard içinde bir şifreleme paketi listesi bulunmaz. Kimlik doğrulamalı şifreleme için ChaCha20-Poly1305, anahtar değişimi için Curve25519, özetleme için BLAKE2s ve anahtar türetme için HKDF kullanılır. Her kurulum bu ilkelleri kullandığından, ayrıştırılacak bir müzakere aşaması veya daha zayıf bir seçeneğe düşürme yolu yoktur. Bu durumun getirdiği ödünleşme nettir: bu ilkellerden biri kırılırsa, çözüm bir yapılandırma değişikliği değil, protokolün tamamının yeni bir sürümünün yayınlanması ve her iki uçta da güncelleme yapılmasıdır. Bu tek karar, TLS tabanlı bir tünelin taşıdığı kodun büyük kısmını ve hata modlarının çoğunu ortadan kaldırır; WireGuard ve OpenVPN karşılaştırması konusundaki temel fark da büyük ölçüde buna dayanır.

Port neden tarayıcıya yanıt vermiyor

Her el sıkışma mesajı mac1 adında bir alan taşır. Bu, yanıtlayıcının statik genel anahtarından türetilen bir anahtarla mesaj üzerinden hesaplanan bir MAC (mesaj kimlik doğrulama kodu) değeridir. Bu genel anahtarı bilmeyen bir gönderici geçerli bir mac1 üretemez ve alıcı, bu tür bir paketi hiçbir yanıt vermeden düşürür. Hata mesajı, bağlantı sıfırlama veya ICMP bildirimi gönderilmez.

Görünen sonuç, hiçbir yanıt döndürmeyen bir UDP taramasıdır.

sudo nmap -sU -p 51820 vpn.example.com

nmap, bir güvenlik duvarının sessizce düşürdüğü port için verdiği yanıtla aynı olan open|filtered sonucunu rapor eder. Port, en azından genel anahtarınıza sahip olmayan herkes için, WireGuard dinlemede olsun ya da olmasın aynı şekilde davranır.

İkinci bir alan olan mac2, hizmet reddi (DoS) baskısını yönetir. Alıcı yük altındayken, geçerli bir başlatma isteğine göndericinin kaynak adresiyle ilişkilendirilmiş 64 baytlık bir çerez yanıtı ile karşılık verir ve gönderici bu çerezi geri gönderene kadar maliyetli genel anahtar işlemlerini yapmayı reddeder. Bu mekanizma, herhangi bir CPU kaynağı harcanmadan önce kaynak adresin gerçek olduğunun kanıtlanmasını sağlar ve yalnızca yük altındayken devreye girer.

Neden 0.0.0.0/0 bir eşi varsayılan rotanız haline getirir

AllowedIPs yönlendirme tablosu olduğu için, AllowedIPs = 0.0.0.0/0, ::/0 o eş için her hedefi talep eder. Bu, tam tünel ayarının tamamıdır.

Bunu çalıştıran yönlendirme mantığı, satırın kendisinden daha ilgi çekicidir. wg0 üzerinden basit bir varsayılan rota döngüye girerdi; çünkü trafiğinizi taşıyan şifreli UDP paketi de makineden çıkmak zorundadır ve kendi varsayılan rotasıyla eşleşirdi. wg-quick, bunu ilke tabanlı yönlendirme (policy routing) ile önler. WireGuard'ın kendi giden paketlerini bir fwmark ile işaretler, tünel varsayılan rotasını ayrı bir yönlendirme tablosuna yerleştirir ve yalnızca işaretsiz trafiğin buraya ulaşmasını sağlayan kurallar ekler. ip rule show komutunu çalıştırdığınızda sonucu görürsünüz:

32764:	from all lookup main suppress_prefixlength 0
32765:	not from all fwmark 0xca6c lookup 51820
32766:	from all lookup main

0xca6c, onaltılık tabanda 51820'dir ve 51820 aynı zamanda tablo numarasıdır. suppress_prefixlength 0 kuralı, ana tablonun kendi varsayılan rotasını atlamasını sağlar; böylece yerel alt ağınız gibi özel rotalar öncelik kazanırken, diğer her şey tünel tablosuna düşer. Ayrık tünel (split tunnel) için bunların hiçbirine gerek yoktur: AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 gibi daha dar bir liste, ana tabloda sıradan rotalar haline gelir.

Tam tünelin tek başına çözmediği bir konu isim çözümlemedir; çünkü istemcinizin yerel ağdan öğrendiği çözümleyici genellikle yerinde kalır ve rotası daha spesifik olduğu için önceliklidir. Bu ayrı bir işlemdir ve WireGuard tüneli dışına sızan DNS başlığında ele alınmıştır.

PersistentKeepalive ne işe yarar

WireGuard, trafik olmadığında hiçbir veri göndermez. Sinyal (heartbeat), oturum yenileme veya hat üzerinde herhangi bir trafik oluşmaz. Bu sessizlik, pil ömrünü uzatır ve yukarıda bahsedilen tarayıcı senaryolarında avantaj sağlar; ancak belirli bir yapılandırmayı işlevsiz kılar.

NAT (network address translation) veya durum bilgisi tutan (stateful) bir güvenlik duvarının arkasındaki bir eş (peer), dış dünyadan yalnızca cihaz üzerinde bir eşleşme (mapping) bulunduğu sürece erişilebilir durumdadır; bu eşleşme ise giden bir paket tarafından oluşturulur. Yaygın UDP eşleşme ömürleri yaklaşık 30 saniyeden başlar. Eşleşme süresi dolduğunda, genel ağ tarafındaki paketler orta kutu (middlebox) tarafından reddedilir ve NAT arkasındaki eş bir veri gönderene kadar tünel ölü görünür. PersistentKeepalive = 25, her 25 saniyede bir boş ve doğrulanmış bir paket göndererek bu en kısa yaygın ömür süresinin altında kalır, böylece eşleşme açık tutulur.

Bu ayarı NAT arkasındaki eş üzerinde yapılandırın. Genel bir IP adresine ve açık bir UDP portuna sahip sunucuların buna ihtiyacı yoktur; bu ayarın orada etkinleştirilmesi yalnızca gereksiz trafik oluşturur. Bunu, bir eş veri aldıktan sonra geri gönderecek bir verisi olmadığında 10 saniye sonra tetiklenen otomatik keepalive ile karıştırmayın. Söz konusu otomatik mekanizma her zaman açıktır ve yapılandırılamaz.

LAN trafiğini tünel üzerinden yönlendirmek bir WireGuard özelliği değildir

B eşinin bir ev ağında 192.168.50.0/24 üzerinde olduğunu ve A eşinin bu ağa erişmesi gerektiğini varsayalım. İki ayrı sistemin birbiriyle uyumlu çalışması gerekir ve bunlardan yalnızca biri WireGuard'dır.

WireGuard'ın sorumluluğu: A üzerindeki B'nin AllowedIPs kısmına 192.168.50.0/24 eklemektir. Bu işlem, A'nın ilgili öneki B'ye yönlendirmesini sağlar ve A'nın B'den gelen, bu kaynak adreslerini taşıyan paketleri kabul etmesine olanak tanır. Bu işlem yapılmazsa, kripto anahtar yönlendirmesi (cryptokey routing) hedef için bir anahtar bulamaz ve kaynak için gerekli izne sahip olmaz.

Çekirdeğin (kernel) sorumluluğu: B üzerinde net.ipv4.ip_forward değeri 1 olmalıdır; aksi takdirde çekirdek, doğrudan B'ye adreslenmemiş olan tüm şifresi çözülmüş paketleri düşürür. B'nin güvenlik duvarındaki forward zincirinin bu trafiğe izin vermesi gerekir. LAN üzerindeki ana bilgisayarların 10.8.0.0/24 adresine geri dönen bir rotaya sahip olması ya da B'nin yanıtların kendisi üzerinden dönmesini sağlamak için kaynak NAT (source NAT) uygulaması gerekir.

WireGuard'ın görevi, şifresi çözülmüş paketi kernel'e teslim ettiğinde sona erer. Bundan sonraki işlemler standart Linux routing ve filtering süreçleridir. Bu nedenle bu hata nft list ruleset sayaçlarında veya ip -s link show wg0 içinde görülür; wg show içinde görülmez. Peer'leri bir web arayüzü üzerinden yönetmek tercih ediliyorsa, Docker üzerinde wg-easy çalıştırma peer kayıtlarını otomatik olarak oluşturur. Ancak forwarding kuralları yine host'a aittir. Bir coordination layer prefix'i sizin için dağıttığında da aynı ayrım geçerlidir: Tailscale subnet router ile VPS üzerinden özel bir ağı duyurma, her peer üzerindeki manuel AllowedIPs düzenlemesinin yerini alır. Ancak router'ın kendisindeki forwarding sysctl ayarı ve firewall kuralları yine tarafınızca yapılandırılmalıdır.

WireGuard neden çekirdek seviyesinde çalışır

wg0 bir ağ aygıtı sürücüsüdür. Paketler normal yönlendirme yığını üzerinden buraya ulaşır, softirq bağlamında şifrelenir ve kullanıcı alanına (userspace) hiç geçmeden bir UDP soketi üzerinden çıkar. Yüksek verimlilik buradan gelir; ayrıca modülün yaklaşık dört bin satır kodda kalmasının nedeni de budur. Bu boyut, kodun incelenmesi ve Mart 2020'de ana hat Linux 5.6 çekirdeğine dahil edilmesi için yeterince küçüktür. Ubuntu 24.04 ve Debian 13 bu modülü içerir, bu nedenle yalnızca wireguard-tools paketi eksiktir.

Normal bir arayüz olmanın pratik sonuçları vardır. tcpdump -ni wg0 şifrelenmemiş iç paketleri gösterirken, tcpdump -ni eth0 udp port 51820 şifrelenmiş dış paketleri gösterir; bu ikisini karşılaştırmak, hangi yöndeki bağlantının koptuğunu anında anlamanızı sağlar. netfilter ve trafik şekillendirme araçları wg0 arayüzüne diğer tüm bağlantılar gibi davranır. Ana makine çekirdeğini paylaşan konteyner sanallaştırma gibi çekirdek modülünün kullanılamadığı durumlarda, wireguard-go aynı protokolü bir TUN aygıtı üzerinde kullanıcı alanında uygular. Ancak her paket çekirdek sınırını iki kez geçtiği için bu durum verimlilikte gerçek bir kayba yol açar.

WireGuard'ın sizi korumadığı durumlar

Tehdit modeli bilinçli olarak dar tutulmuştur ve bu kadar sessiz bir protokol, beklentilerin gerçek dışı olmasına yol açabilir. Durumu açıkça belirtelim.

• WireGuard kullandığınızı gizlemez. El sıkışma (handshake) mesajları sabit boyutlara sahiptir, ilk bayt mesaj türünü belirtir ve taşıma protokolü UDP'dir. Derin paket incelemesi (DPI) bunu kolayca tanır ve VPN trafiğinden hoşlanmayan bir ağ bunu engelleyebilir. Karartma (obfuscation) özelliği, tasarım gereği dahil edilmemiştir.
• Trafik hacmini veya zamanlamasını gizlemez. Yükler (payload) yalnızca 16 baytlık sınırlara kadar doldurulur (padding), bu nedenle bir gözlemci ne zaman veri gönderdiğinizi ve yaklaşık ne kadar gönderdiğinizi görmeye devam eder.
• Bilinen son uç noktayı tutar. Genel IP adresine sahip olan eş (peer), diğer tarafın güncel genel IP adresini saklar ve wg show bunu görüntüler. Yapılandırmada sabit olan tünel adresiyle birlikte bu, kullanıcıyı ağlar arasında takip eden kararlı bir tanımlayıcıdır. Kendi VPS'nizde bu bir sorun teşkil etmez. Ticari servislerin protokolün üzerine bir katman daha eklemesinin nedeni de budur.
• Bir kişiyi değil, bir anahtarı doğrular. Özel anahtar dosyasına sahip olan kişi eştir. /etc/wireguard dizinini 700, anahtar dosyalarını ise 600 modunda tutun.
• İptal listesi veya son kullanma tarihi yoktur. Erişim, eş girişini onu tutan tüm sunuculardan sildiğinizde sona erer ve statik anahtarlar siz onları kaldırana kadar geçerli kalır.

Bunların hiçbiri WireGuard'ı zayıf kılmaz. Aksine onu küçük kılar ve önemli olan da budur: protokol doğrular ve şifreler; kimlik yönetimi ve adres tahsisini ise üzerine inşa ettiğiniz yapıya bırakır. WireGuard ve Tailscale karşılaştırması bölümünde açıklanan türden bir koordinasyon katmanı, az önce okuduğunuz veri düzlemini kullanarak tam olarak bu boşluğu doldurmak için mevcuttur. Böyle bir katman kurulduğunda, bir sonraki karar tünel içinde çalıştırdığınız bir servise kimin erişebileceğidir; Tailscale serve ve funnel arasındaki seçim konusu, tek bir port için bu sorunu çözmektedir.

FAQ

WireGuard içinde cryptokey routing nedir?

Cryptokey routing, her paketi bir public key ile ilişkilendiren kuraldır. Her peer girdisi, AllowedIPs içinde bir önek listesi taşır. Giden trafikte WireGuard, paketin hedef adresini her peer'in listesiyle (en uzun önek öncelikli olacak şekilde) eşleştirerek peer seçimini yapar; dolayısıyla bu liste bir yönlendirme tablosu işlevi görür. Gelen trafikte ise paket şifresi çözülüp doğrulandıktan sonra, paketin iç kaynak adresi aynı peer'in listesi içinde yer almalıdır; aksi takdirde paket düşürülür. Bu nedenle liste, bir erişim kontrol listesi (ACL) görevi de görür. WireGuard'da ayrı bir yönlendirme yapılandırması veya dahili güvenlik duvarı yoktur, çünkü bu tek liste her iki işi de yapar.

Her iki peer üzerinde de PersistentKeepalive ayarına ihtiyacım var mı?

Hayır. Bu ayarı, genellikle istemci tarafı olan, NAT (network address translation) arkasındaki veya durum bilgisi tutan (stateful) bir güvenlik duvarının arkasındaki tarafta yapılandırın. WireGuard boşta kaldığında hiçbir veri göndermez; bu nedenle karşı tarafın o peer'e ulaşmasını sağlayan eşleme süresi (genellikle bir dakika içinde) dolar ve tünel tek yönde ölü görünür. PersistentKeepalive = 25, her 25 saniyede bir boş ve doğrulanmış bir paket göndererek eşlemenin açık kalmasını sağlar. Genel bir IP adresine ve açık bir UDP portuna sahip bir peer'in bu ayara ihtiyacı yoktur.

Tünel üzerinden atılan ping neden "Required key not available" hatası veriyor?

Çünkü hedef adres, hiçbir peer'in AllowedIPs listesinde yer almıyor. Bu durumda cryptokey routing, paketi şifrelemek için bir anahtar bulamaz ve kernel paketi göndermeyi reddeder. wg show wg0 allowed-ips komutunu çalıştırın ve çıktıyı ping attığınız adresle karşılaştırın. Benzer bir hata olan Destination address required ise farklı bir sorundur: Bir peer eşleşmiştir ancak WireGuard'ın o peer için bir endpoint bilgisi yoktur; çünkü hiçbir endpoint yapılandırılmamış ve o peer'den henüz doğrulanmış bir paket gelmemiştir.

Bir güvenlik duvarı WireGuard'ı tespit edip engelleyebilir mi?

Evet. WireGuard trafiğinizi doğrular ve şifreler, ancak kendini gizlemek için herhangi bir girişimde bulunmaz. El sıkışma (handshake) mesajları sabit 148 ve 92 bayt boyutundadır, her mesajın ilk baytı türünü tanımlar ve taşıma protokolü UDP'dir. Bu nedenle derin paket incelemesi (DPI) protokolü zorlanmadan tanımlar. UDP trafiğini engelleyen veya protokolleri parmak izi yöntemiyle tanıyan ağlar, WireGuard'ı durduracaktır. Tüneli gizlemek, onu başka bir yapı içine sarmalamayı gerektirir; bu ise bir WireGuard ayarı değil, harici bir araç gerektiren ayrı bir işlemdir.