WireGuard el sıkışması çalışıyor ama internet yok: paketi izleyin

Tünel ayakta, wg show yakın zamanda bir el sıkışma bildiriyor, sunucunun tünel adresine ping atabiliyorsunuz ve ötesinden hiçbir yanıt gelmiyor. İlk dürtü anahtarları yeniden üretmek veya yapılandırmayı yeniden paylaşmaktır. Bu, yolun zaten çalıştığı kanıtlanmış olan kısmını değiştirir.

Tamamlanmış bir el sıkışma, iki tarafın anahtarlar üzerinde anlaştığını, UDP'nin uç noktaya ulaştığını ve kripto yönlendirmenin paketi kabul ettiğini söyler. Paketin sonrasında sunucudan çıkıp çıkamayacağı hakkında hiçbir şey söylemez.

Bu yüzden tahmin etmek yerine tek bir paketi izleyin. Ölebileceği dört yer vardır ve her biri farklı bir iz bırakır.

El sıkışma gerçekte neyi kanıtlar

WireGuard, Noise el sıkışmasıyla oturum kuran ve ardından bir eş için paketleri şifreleyen bir UDP protokolüdür. wg show birkaç saniyelik bir el sıkışma ve artan aktarım sayacı gösterdiğinde uç nokta, anahtarlar ve eşin ortak anahtarı hepsi doğrudur.

Kanıtlamadığı şey, istemcinizin internete giden trafiği arayüze gönderip göndermediği, sunucunun onu iletmeye istekli olup olmadığı veya bir yanıtın dönüş yolunu bulup bulamayacağıdır. Bunlar çekirdek yönlendirmesi ve güvenlik duvarı kararlarıdır ve tünelin dışında alınırlar.

Sunucunun tünel adresine ping atmak bu yüzden böylesine yanıltıcı bir testtir. O paket sunucunun kendisine adreslenmiş, dolayısıyla yerel olarak sonlanır. Hiçbir zaman yönlendirmeye, hiçbir zaman çeviriye ve hiçbir zaman internetten bir dönüş rotasına ihtiyaç duymaz.

AllowedIPs bir yönlendirme kararıdır

İstemcide AllowedIPs iki iş yapar. Hangi hedef adreslerin bu eşin tüneline gireceğine karar veren kripto anahtar yönlendirme tablosudur ve eşin sizden kabul edeceği kaynak adreslerin listesidir. İstemci yapılandırması yalnızca 10.8.0.0/24 listeliyorsa, genel hedefler arayüze hiç girmez ve normal varsayılan rotanız onları tünelin dışına taşır. O zaman tünel kusursuz çalışır ve istediğiniz hiçbir şeyi yapmaz.

Yapılandırma dosyasının söylediğine değil, istemcinin gerçekte ne kurduğuna bakın:

wg show wg0 allowed-ips
ip route get 1.1.1.1

İkinci komut belirleyicidir. Yanıt fiziksel arayüzünüzü ve olağan ağ geçidini adlandırıyorsa paket tünellenmiyordur ve sunucu tarafındaki hiçbir değişiklik bunu düzeltmez. IPv4 için 0.0.0.0/0 ve IPv6 için ::/0 ayrı ayrı ekleyin; bir aile için her şeyi yakalayan bir kural diğerini kendi özgün yolunda bırakır ve bu, çalışan bir IPv4 tüneli ile takılı kalmış bir IPv6 aramasının yaygın nedenidir.

Paket ağ geçidinde nerede ölür

Rota doğruysa ve paket hâlâ hiçbir yere gitmiyorsa sunucuya ulaşır ve orada durur. Dört kontrol çoğu ağ geçidini kapsar.

Yönlendirme. sysctl net.ipv4.ip_forward komutunun 0 döndürmesi klasik yanıttır ve birçok dağıtım varsayılan olarak hâlâ 0'dadır. 1 olmalıdır ve yeniden başlatmada kaybolan bir komutla değil, bir sysctl dosyasında kalıcı olarak ayarlanmalıdır. IPv6 yönlendirmesi ayrı bir anahtardır.

Filtre politikası. Varsayılan drop politikası olan bir FORWARD zinciri tünel trafiğini atarken ana makinenin kendisine giden trafiğe izin verir, ki bu belirtiyle tam olarak örtüşür. Kaydedilmiş bir dosyayı değil, canlı kural kümesini okuyun: nft list ruleset veya iptables -S.

Çeviri veya yönlendirme. Özel tünel adresleri kullanan istemciler, ya sunucunun çıkış arayüzünde kaynak NAT'a ya da üst ağın nasıl geri döndüreceğini bildiği yönlendirilmiş bir öneke ihtiyaç duyar. İkisi arasındaki seçim adres planını izler. Önekinizi zaten geri yönlendiren bir ağa MASQUERADE eklemek zararsız ama anlamsızdır; rota olmayan bir yerde onu atlamak ise yanıtları yönlendirilemez özel bir aralığa adreslenmiş bırakır.

Dönüş yolu. Yönlendirilmiş tasarımlarda üstteki yönlendiricinin sunucunuza işaret eden bir rotaya ihtiyacı vardır. Sağlayıcının ağı bunu engelleyebilir de: birkaç bulut örnek üzerinde kaynak ve hedef denetimini açar ve bu denetim kapatılana kadar kaynağı örneğin kendi adresi olmayan paketleri sessizce düşürür.

DNS yönlendirmeden farklı biçimde başarısız olur

Bilinen bir adrese giden paket ile ad çözümlemesi iki ayrı arızadır ve hata mesajları zıt yönlerde yanıltır. ping 1.1.1.1 çalışıp tarayıcı hiçbir şey yükleyemiyorsa rota iyidir, ad çözümlemesi değildir. Ping'in kendisi başarısız oluyorsa DNS konu dışıdır ve önceki bölüme dönmüşsünüzdür.

wg-quick yapılandırmadaki DNS = satırından bir çözümleyici ayarlayabilir ve systemd-resolved'ın her bağlantı için kendi davranışı vardır. Çözümleyiciyi yalnızca tünelin içinden erişilebilen bir adresle ezen bir VPN, tünel düştüğü anda her aramayı başarısız kılar; bu da tünelin interneti bozduğu gibi görünür.

Kanıt üreten bir sıra

Önce istemci tarafındaki kontrolü çalıştırın, çünkü tek bir komuttur ve olasılıkların yarısını eler. Sonra sunucunun baştan beri internet çıkışı olarak tasarlanıp tasarlanmadığını doğrulayın; özel erişim için kurulmuş bir ağ geçidi, genel hedefler başarısız olduğunda bozuk değildir.

Sunucuda, istemciden ping gönderirken arayüzü izleyin: tcpdump -ni wg0 icmp isteği göstermeli ve tcpdump -ni eth0 icmp çevrilmiş olsun ya da olmasın dışarı çıktığını göstermelidir. Birincide görünüp ikincide hiç görünmüyorsa durma sunucuda yereldir. Dışarı çıkıp yanıt dönmüyorsa sorun yukarıdadır ve bu başka bir konuşmadır.

Son olarak düzeltmenin yeniden başlatmayı atlatmasını sağlayın. Yönlendirme bir sysctl dosyasına, güvenlik duvarı kuralları onları yükleyen hizmete, istemci rotaları ise arayüzü kaldıran yapılandırmaya aittir; unutacağınız bir kabuğa değil. Yeniden bağlanın, aynı iki testi tekrarlayın ve sayaçların hareket ettiğini doğrulayın.