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

WireGuard'ın çalışma mantığı: tek bir fikir

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 adresiyle 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 kurulumunu yapın 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 aygıtı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 tanımlar; bu eş bir genel anahtarı, o da bir oturum anahtarını ve bir UDP uç noktasını tanımlar. 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 anahtar mevcut değildir.

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ı belirtir; çünkü ne yapılandırılmıştır ne de henüz öğ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ü (payload) ş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 ve başka hiçbir adresten paket gönderebilir. Oraya 0.0.0.0/0 yazarsanız, bu tek istemcinin tüneliniz içindeki herhangi bir kaynak adresini, başka bir istemcinin adresi dahil olmak üzere, kullanmasına izin verilmiş olur.

Örtüşen önekler, arama işlemi en uzun önek eşleşmesi (longest prefix match) yöntemiyle yapıldığından, özgüllük derecesine göre çözümlenir. İki eş üzerindeki aynı önekler farklı davranır: girdi, 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 gerçek 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, herhangi bir rolde değil, değerlerin kendisindedir.

Bu anahtarların yarısı aslında protokole dahil değildir. Address, DNS, MTU, PostUp ve SaveConfig, arayüzü ayağa kaldıran kabuk betiği olan wg-quick bileşenine aittir. Çekirdek bunları asla görmez. wg-quick strip wg0, wg aracının fiilen yüklediği sadeleştirilmiş 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 faydalı 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 şifrelenmiş 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 el sıkışma başına yeni bir geçici Curve25519 anahtar çifti oluşturur; oturum anahtarları ise 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 biri, gelecek yıl sunucunun özel anahtarını çalsa bile kaydettiği verileri okuyamaz.

El sıkışma başlatma mesajı bir 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 (replayed) 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 ihtiyaç duyulmadan yeniden oynatma ve yoğun paket sıralama bozuklukları yönetilir.

Oturum anahtarları uzun ömürlü değildir 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 protokol spesifikasyonundaki sabitlerdir, ölçüm değerleri değildir. 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 değerini göreceli bir yaş olarak yazdırmasının ve yoğun, sağlıklı bir tünelin bu yaşı neden küçük tuttuğunun sebebi budur. Aktif olarak trafik gönderdiğiniz sırada artan bir yaş değeri, tünelin boşta olduğu anlamına değil, el sıkışmaların başarısız olduğu anlamına gelir.

Bir eşin neden istemci veya sunucu rolü yoktur

Her iki uç da aynı kodu ve aynı yapılandırma formatını çalıştırır. Sunucu modu yoktur. Hissettiğiniz asimetri Endpoint kaynaklıdır ve Endpoint isteğe bağlıdır.

Yapılandırılmış bir endpoint'e sahip olan eş, bir el sıkışma (handshake) başlatabilir. Buna sahip olmayan eş ise bekler; ardından doğru şekilde kimlik doğrulaması yapılan ilk paketten karşı tarafın adresini ve portunu öğrenir. Öğrenilen bu endpoint depolanır ve yeni bir adresten geçerli bir paket 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 korur, çünkü oturum IP adresinden ziyade anahtar ve indeks ile tanımlanır. Hiçbir şey yeniden bağlanmaz, çünkü TCP anlamında hiçbir zaman bir bağlantı kurulmamıştır.

Aynı mekanizma, bilinmesi gereken bir gerçeği ortaya çıkarır: genel adrese 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 (ciphersuite) listesi bulunmaz. Kimlik doğrulamalı şifreleme için ChaCha20-Poly1305, anahtar değişimi için Curve25519, özetleme (hashing) 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 (downgrade) yolu yoktur. Bu durumun getirdiği ödünleşme nettir: Eğer bu ilkellerden biri kırılırsa, çözüm 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 bir kısmını ve hata modlarının çoğunu ortadan kaldırır; WireGuard ve OpenVPN karşılaştırması başlığındaki kıyaslamanın temel dayanağı da büyük ölçüde budur.

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 üzerinde hesaplanan bir MAC (mesaj kimlik doğrulama kodu) değeridir. O 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.

Bunun gözlemlenebilir sonucu, 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ı tarafından sessizce düşürülen portlar için verdiği yanıtla aynı olan open|filtered sonucunu raporlar. 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 yansıtana 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 sahiplenir. 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 düz 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 politika 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 koyar 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ü korumaya ve yukarıda bahsedilen tarayıcı senaryolarında yardımcı olur; ancak belirli bir yapılandırmayı işlevsiz kılar.

NAT (ağ adresi çevirisi) veya durum bilgisi tutan (stateful) bir güvenlik duvarının arkasındaki bir eş (peer), dış dünyadan yalnızca ilgili cihazda bir eşleşme (mapping) mevcut olduğu sürece erişilebilirdir; bu eşleşme ise giden bir paket tarafından oluşturulur. Yaygın UDP eşleşme ömürleri yaklaşık 30 saniye civarında başlar. Eşleşme süresi dolduğunda, genel ağ tarafındaki paketler ara cihaz (middlebox) tarafından düşürülür 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 kimliği doğrulanmış bir paket gönderir; bu süre en kısa yaygın eşleşme ömrünün altında kaldığı için eşleşme açık kalır.

Bu ayarı NAT arkasındaki eş üzerinde yapılandırın. Genel bir IP adresine ve açık bir UDP portuna sahip bir sunucunun buna ihtiyacı yoktur; orada yapılandırmak 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 canlı tutma (keepalive) mekanizmasıyla karıştırmayın. O mekanizma her zaman etkindir ve yapılandırılamaz.

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

B eşinin 192.168.50.0/24 ev ağında 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 görevi: 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 adreslerine sahip 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) görevi: B üzerinde net.ipv4.ip_forward değeri 1 olmalıdır; aksi takdirde çekirdek, doğrudan B'ye adreslenmemiş şifresi çözülmüş her paketi reddeder. B'nin güvenlik duvarındaki forward zinciri trafiğe izin vermelidir. LAN üzerindeki ana bilgisayarların 10.8.0.0/24 adresine geri dönen bir rotaya sahip olması gerekir veya B'nin yanıtların kendisi üzerinden dönmesi için kaynak NAT (source NAT) uygulaması gerekir.

WireGuard'ın işi, şifresi çözülmüş paketi çekirdeğe teslim ettiğinde biter. Bundan sonraki süreç standart Linux yönlendirme ve filtreleme işlemleridir; bu nedenle bu tür hatalar wg show içinde değil, nft list ruleset sayaçlarında veya ip -s link show wg0 içinde görünür. Eşleri bir web arayüzü üzerinden yönetmeyi tercih ederseniz, Docker üzerinde wg-easy çalıştırmak sizin için eş kayıtlarını oluşturur; ancak yönlendirme kuralları yine de ana bilgisayarın sorumluluğundadı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'ya 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 olmasını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. Çekirdek modülünün kullanılamadığı, ana makine çekirdeğini paylaşan konteyner sanallaştırma gibi 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 neden olur.

WireGuard'ın sizi korumadığı durumlar

Tehdit modeli kasıtlı 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 katmanı UDP'dir. Derin paket incelemesi (DPI) bunu kolayca tanır ve VPN kullanımını kısıtlayan bir ağ, trafiği engelleyebilir. Karartma (obfuscation) özelliği, tasarım gereği dahil edilmemiştir.
• Trafik hacmini veya zamanlamasını gizlemez. Yükler (payloads) yalnızca 16 baytlık sınırlara göre doldurulur; bu nedenle bir gözlemci, ne zaman veri gönderdiğinizi ve yaklaşık ne kadar veri aktardığınızı görmeye devam eder.
• Bilinen son uç noktayı tutar. Genel IP adresine sahip olan eş (peer), karşı tarafın güncel genel IP adresini saklar ve wg show bunu görüntüler. Yapılandırma dosyasında sabitlenmiş bir tünel adresiyle birlikte bu, kullanıcı ağlar arasında geçiş yaparken onu takip eden sabit bir tanımlayıcı oluşturur. Kendi VPS'nizde bu bir sorun teşkil etmez. Ticari servislerin protokolün üzerine ek bir katman inşa etmesinin 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 modunda, anahtar dosyalarını ise 600 modunda tutun.
• İptal listesi veya son kullanma tarihi yoktur. Erişim, eş kaydını onu tutan her sunucudan sildiğinizde sona erer; statik anahtarlar siz onları kaldırana kadar geçerliliğini korur.

Bunların hiçbiri WireGuard'ı zayıf kılmaz. Aksine, onu küçük kılar ve amaç da budur: Protokol, kimlik doğrulama ve şifreleme işlemlerini gerçekleştirir; 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.

FAQ

WireGuard'da 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'ın listesiyle eşleştirerek (en uzun önek öncelikli olacak şekilde) peer seçimini yapar; bu nedenle 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'ın listesi içinde yer almalıdır; aksi takdirde paket düşürülür. Bu nedenle liste, bir erişim kontrol listesi işlevi 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.

PersistentKeepalive ayarını her iki peer üzerinde de yapmalı mıyım?

Hayır. Bu ayarı, NAT (network address translation) arkasında veya durum bilgisi tutan (stateful) bir güvenlik duvarının arkasında bulunan tarafta, yani genellikle istemcide yapın. WireGuard boşta kaldığında hiçbir veri göndermez; bu nedenle karşı tarafın o peer'a ulaşmasını sağlayan eşleme genellikle bir dakika içinde zaman aşımına uğrar 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şlemeyi açık tutar. Genel bir IP adresine ve açık bir UDP portuna sahip bir peer'ın bu ayara ihtiyacı yoktur.

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

Çünkü hedef adres, hiçbir peer'ın AllowedIPs listesinde yer almamaktadır. Bu durumda cryptokey routing, paketi şifrelemek için herhangi 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ü herhangi bir endpoint yapılandırılmamış ve o peer'dan 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 (deep packet inspection) protokolü zorlanmadan tanımlar. UDP trafiğini engelleyen veya protokolleri parmak izi yöntemiyle tespit eden 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 aracın konusudur.