Semptom
Bir Windows iş istasyonunun tüm internet trafiğini uzak bir sunucudan çıkarmak için WireGuard tam tünel kurdum. Sunucu tarafı hazırdı ve başka bir istemci aynı sunucuya sorunsuz bağlanıyordu. Windows tarafında ise tünel arayüzü şunu gösteriyordu:
Aktarım: 740 B gönderildi, 0 B alındı
En son el sıkışma: (hiç)Yani istemci konuşuyordu, karşı taraf hiç cevap vermiyordu. Klasik teşhis burada "sunucu erişilemiyor" veya "anahtarlar yanlış" der. İkisi de değildi.
İlk eleme: sunucu paketi görüyor mu?
Bu vakayı çözen ilk hamle, tahmin etmeyi bırakıp paketin nereye kadar gittiğine bakmak oldu. Sunucuda dinledim:
tcpdump -ni eth0 udp port 51820
# İstemci "bağlan" derken:
# (hiçbir paket düşmüyor)İstemci 740 bayt gönderdiğini söylüyor, sunucu tek paket görmüyor. Demek ki paket istemcinin kendi makinesinden çıkmıyor — sorun aradaki ağda değil, istemcinin içinde.
Bu, aramayı bir anda daraltıyor: anahtar, port, sunucu yapılandırması ve güvenlik duvarı kuralları listeden çıkıyor.
Yanlış şüpheli
Makinede bir antivirüs ve eski bir VPN istemcisi vardı. İnternette bu semptomun cevabı neredeyse her zaman "antivirüsü kaldır" oluyor. Kaldırdım — değişmedi. Bir düzeltmeyi denedikten sonra sonuç değişmediyse, o düzeltmeyi hipotez listesinden silmek gerekir; oysa insan genelde "yeterince kaldırmadım" diye aynı yolda ısrar ediyor.
Doğru soru şuydu: bu makineden genel olarak UDP çıkıyor mu, yoksa yalnızca WireGuard'ın paketi mi çıkmıyor?
$c = New-Object System.Net.Sockets.UdpClient
$b = [Text.Encoding]::ASCII.GetBytes("test")
$c.Send($b, $b.Length, "sunucu-adresi", 51820)Bu paket sunucuya ulaştı (tcpdump gördü). Genel UDP çıkıyor, WireGuard'ın paketi çıkmıyor. Sorun ağda değil, WireGuard'ın soketi nereye bağladığında.
Kök neden
Makine çok arayüzlüydü: fiziksel Ethernet, ikinci bir yerel ağ bağlantısı ve Hyper-V'nin oluşturduğu sanal anahtar — üçünün de varsayılan ağ geçidi tanımı vardı.
Get-NetRoute -DestinationPrefix 0.0.0.0/0 |
Select-Object ifIndex, NextHop, RouteMetric, InterfaceMetric
ifIndex NextHop RouteMetric InterfaceMetric
------- ------- ----------- ---------------
12 192.0.2.1 0 15
18 198.51.100.1 0 25
20 203.0.113.1 0 35WireGuard giden soketini en düşük toplam metriğe sahip arayüze bağlıyordu. Ne yazık ki o arayüz, ağdaki güvenlik duvarının çıkışa izin vermediği segmentteydi — yani teknik olarak "en iyi" ama pratikte ölü bir yol. Gerçek internet çıkışı en yüksek metrikli üçüncü arayüzdeydi.
İstemci paketi doğru şekilde üretiyor, doğru şekilde şifreliyor ve yanlış kapıdan atıyordu. Sayaçtaki "740 B gönderildi" bu yüzden dürüsttü: paket gerçekten gönderilmişti, sadece hiçbir yere varmıyordu.
Çok arayüzlü bir makinede "internet var" ile "senin uygulamanın kullandığı arayüzde internet var" aynı şey değildir. Tarayıcı çalışıyor olabilir çünkü o başka bir yol seçmiştir. VPN istemcileri giden soketi rota metriğine göre bağlar — metrik yanlışsa uygulama sessizce boşluğa konuşur.
Çözüm
Gerçek çıkışı olan arayüz birincil yapıldı, diğerleri açıkça geriye itildi:
# Gerçek internet çıkışı olan arayüz öne
Set-NetIPInterface -InterfaceIndex 20 -InterfaceMetric 1
# Ölü yollar arkaya
Set-NetIPInterface -InterfaceIndex 12 -InterfaceMetric 9001
Set-NetIPInterface -InterfaceIndex 18 -InterfaceMetric 9002En son el sıkışma: 3 saniye önce
Aktarım: 4.21 KiB gönderildi, 6.83 KiB alındıMetrik değişikliğinden sonra tünel ilk denemede kuruldu; çıkış IP'si doğrulandı.
Kalıcı ders
- "Gönderildi" sayacı varmayı garanti etmez. Gönderilen bayt, yerel soketten çıkan bayttır. Karşı tarafta doğrulamadan bunu başarı sanma.
- Ayırt edici test kur. "UDP çıkıyor mu?" ile "WireGuard'ın UDP'si çıkıyor mu?" sorularını ayırmak, aramayı tüm ağdan tek bir soket kararına indirdi.
- Denediğin çözüm işe yaramadıysa listeden sil. Antivirüs kaldırıldıktan sonra semptom aynıysa antivirüs suçlu değildir. Aynı hipoteze geri dönmek en pahalı zaman kaybı.
- Hyper-V, WSL, Docker Desktop kurulu her Windows makinesi çok arayüzlüdür. Bu tuzak istisna değil, giderek yaygınlaşan varsayılan durum.