WireGuard tam tünel: AllowedIPs 0.0.0.0/0 yeterli değil

Bir eşin AllowedIPs alanına 0.0.0.0/0, ::/0 yazmak herkesin hatırladığı adımdır ve yalnızca eşin hangi trafiği taşıyabileceğine karar verir. Bu önekler hiçbir yol oluşturmaz, karşı tarafta hiçbir şey iletmez ve her uygulamanın çözümleyicisini tam olduğu yerde bırakır. Tam bir tünelin gerçekten tam olması için dört ayrı şeyin aynı anda doğru olması gerekir ve bunları aşağıdaki sırayla denetlemek en iyisidir, çünkü sonraki bir denetim öncekini kurtaramaz. Aşağıdaki her denetim makineden okunabilen bir olgudur, uygulandığını umduğunuz bir ayar değil.

Eş öneki neyi seçer ve neyi seçmez

AllowedIPs aynı zamanda hem seçici hem yetkidir. Yerel tarafa hangi hedeflerin bu eşe gönderilebileceğini, alıcı tarafa ise bu eşin hangi kaynak adresleri sunabileceğini söyler. Bütün iş budur. Bu tanımlamada hiçbir şey ana makinede yol oluşturmaz, uzak tarafta iletmeyi açmaz veya ad çözümlemesine dokunmaz.

Bu yüzden bir yapılandırma tam görünebilir ve bölünmüş tünel gibi davranabilir. Önek eşin her şeyi kabul edeceğini söyler; ana makinenin yönlendirme tablosu oraya gerçekte neyin ulaştığına, ağ geçidi ise bir şeyin çıkıp çıkmadığına karar verir. Bu üç karardan hiçbiri eş bölümünde yaşamaz.

İstemciyi yönlendirmek, yalnızca eş listesini değil

Şunun gibi yöneticiler wg-quick ana makinenin yönlendirme tablosunu sizin yerinize programlar, bu yüzden iki özdeş yapılandırma dosyası arayüzün nasıl kalktığına bağlı olarak farklı davranır. En küçük profil tek seferde okunacak kadar kısadır:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

İşi iki ayrıntı taşır. Address alanı istemcinin kendisine ait sandığı bir alt ağ değil, tek bir ana makine önekidir, ve varsayılan AllowedIPs'i gerçek bir varsayılan yola çeviren yöneticidir. Aynı dosyayı ip link ve wg setconf ile kaldırın, hiçbir yol görünmez; bu bozuk bir tünel gibi görünür ama aslında yönlendirme adımı atlanmış sağlıklı bir tüneldir. wg-quick kılavuzu yönlendirmeyi ve bu yöneticilerin eklediği Table davranışı belgeler.

Dosyayı değil sonucu okuyun: ip route get 1.1.1.1 tünel arayüzünü adlandırmalı ve wg show hareket eden bir aktarım sayacıyla son el sıkışmayı bildirmelidir. Yolsuz bir el sıkışma yöneticinin hiç çalışmadığı anlamına gelir ve profili yeniden düzenlemek bunu düzeltmez. Arayüzü kullanıcının başlatacağı gibi başlatın, yoksa test dağıtımı değil sizin kabuğunuzu ölçer.

Uç noktayı tünelin dışında tutmak

Tam tünel, var olmak için konuşması gereken hedef de dahil her hedefi yakalar. Yöneticiler bunu, uç nokta için özgün ağ geçidi üzerinden bir ana makine yolu ekleyerek çözer, bu yüzden doğru bir yapılandırma neredeyse her zaman tek bir bilinçli istisna içerir. Yapılandırmanın yarısını yöneticiyle, diğer yarısını elle uygulamak bu istisnanın kaybolmasının olağan yoludur.

Uç nokta birkaç adrese veya taşımadığınız bir adres ailesine çözülen bir ana makine adıysa istisna kötü yaşlanır ve rutin görünen bir yeniden bağlanmadan sonra tünel başarısız olabilir. Uç noktayı denetlediğiniz bir adrese sabitleyin veya yöneticinin onu yeniden değerlendirdiğini doğrulayın ve her ağ değişikliğinden sonra ana makine yolunu yeniden okuyun.

Aynı mekanizma tam bir tünel ile yakalama portalının neden çatıştığını açıklar. Portal, tünelinizin artık yakaladığı trafiği kesmeyi bekler; bu yüzden otel ve havalimanı ağlarında tüneli portal oturumundan sonra kaldırırsınız, asla önce değil.

Ağ geçidinde iletme ve dönüş yolu

Ağ geçidinde taşıdığınız aile için iletmeyi açın, çeviri yaparken forward zincirine iki yönde izin verin ve dönüş yolunu kaynağa özgü bir aramayla doğrulayın. Bunların hiçbiri başarılı bir el sıkışmadan doğmaz, çünkü el sıkışma yalnızca iki eşin UDP alışverişi yapabildiğini kanıtlar. Kapsülü çözülmüş pakete sonra ne olduğu hakkında hiçbir şey söylemez.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Arama istemcide değil ağ geçidinde çalışır, yoksa başka bir yönlendirme tablosu okursunuz. Yanlış arayüzü adlandırırsa veya yol yok diye bildirirse, istemci tarafındaki hiçbir değişiklik internet çıkışı üretmez. Ağ geçidi çıkışta istemci adreslerini çevirdiğinde yanıt bu çeviri durumuna bağlıdır, bu nedenle kural akışın yalnızca giden yönü için değil iki yönü için de bulunmalıdır.

DNS ve hata durumu, ayrı ayrı test edilir

Protokolün kendisi hiçbir uygulamanın çözümleyicisini yapılandırmaz. wg-quick, DNS satırını dağıtımın çözümleyici entegrasyonu üzerinden uygular, kendi yığınları olan konteynerler ve tarayıcılar bunu yok sayabilir ve bu yüzden tünel paketleri kusursuz taşırken bir ad başarısız olabilir. Adres yerine ana makine adıyla test edin ve profildeki sunucunun yanıtladığını varsaymak yerine hangi sunucunun yanıtladığını not edin.

Adres aileleri ayrı yanıtı olan ayrı bir testtir. v4 için varsayılan yol, bir uygulamanın v6 bağlantısının ne yapacağı hakkında hiçbir şey söylemez ve ikinci aileyi sessizce sızdıran bir tünel, yüksek sesle başarısız olan bir tünelden daha kötüdür. Her aile üzerinden bir ad sorun, her isteğin kullandığı arayüzü okuyun ve çeviri sayaçlarını önce ve sonra denetleyin, çünkü hiçbir şeyle eşleşmeyen bir kural eksik bir kural gibi görünür.

Son olarak tünel durduğunda istediğiniz durumu test edin. Tam bir tünel, iddia ettiği trafik için kapalı biçimde başarısız olmalıdır: arayüz düşerse ve uygulamalar fiziksel bağlantı üzerinden sessizce devam ederse, tasarım ek adımlı bir bölünmüş tüneldir. Amaçlanan hata davranışını yazın, bilinçli olarak denetleyin ve dört yanıtı kaydederek bitirin — hangi yönetici arayüzü kaldırır, hangi yol varsayılanı taşır, ağ geçidinde kim iletir ve çevirir, ve hangi çözümleyici yanıtlar.