Bir Mesh Wi-Fi uydusunun VPN yönlendiricisini kullanıp kullanmadığı nasıl anlaşılır

Temel yönlendiriciyle aynı Wi-Fi adına yanıt veren bir uydu, istemcilerinin paketlerinin nereye gittiği hakkında neredeyse hiçbir şey söylemez. Düğüm, aksi kanıtlanana kadar bir radyo ve bir köprüdür. Çıkışı belirleyen, her istemcinin aldığı varsayılan ağ geçidi ve önündeki düğümün iletim modudur. Bu beş kontrolü istemciden dışarı doğru yapın; hız testinden kalan bir izlenim yerine savunabileceğiniz bir yanıtınız olsun.

İstemcinin gerçekte aldığı ağ geçidini okuyun

İstemcide yönlendirme tablosunu ve komşu tablosunu yazdırın. Varsayılan yol, trafiği ileten adresi adlandırır; komşu kaydı o adrese sahip MAC’i adlandırır. Yönlendiricinin cihaz listesini değil istemciyi kullanın, çünkü bir cihaz listesi ilişkileri gösterir, yolları değil.

ip route show default
ip -6 route show default
ip neigh show

Windows aynı gerçekleri başka bir biçimde yazdırır: ipconfig /all varsayılan ağ geçidini verir ve arp -a MAC’i verir. macOS’ta route -n get default ile arp -an aynı işi görür.

Bu ağ geçidini zaten bildiğiniz iki adresle karşılaştırın: temel yönlendiricinin LAN adresi ve uydunun yönetim adresi. Ağ geçidi yönlendiricinin LAN adresiyse istemci yönlendiriciye köprülenmiştir ve yönlendiricinin o ağ için politikası değişmeden geçerlidir. Ağ geçidi uydunun adresiyse uydu yönlendirme yapıyordur ve yönlendirici istemcinin paketlerini hiçbir zaman LAN trafiği olarak görmez; karar düğümde verilmelidir, yoksa hiç verilmez.

Düğümün gerçekte hangi modda olduğunu doğrulayın

Mesh ürünleri farklı davranışlar için üç kelimeyi yeniden kullanır, bu yüzden uygulamadaki etiketten çok paket yoluna güvenin. Köprü veya erişim noktası modu çerçeveleri iletir. Yönlendirici modu bir alt ağı sonlandırır ve DHCP çalıştırır. Misafir modu genellikle istemcileri kendi kuralları olan ayrı bir VLAN’a yerleştirir. Başka bir yönlendiricinin arkasındaki yönlendirici modundaki düğüm çift NAT’tır ve istemcileri VPN yönlendiricisine zaten çevrilmiş olarak ulaşır, bu da kaynak adrese dayalı politikayı boşa çıkarır.

MAC’i belirlemek için düğümdeki etiketi okuyun ve bununla karşılaştırın: ip neigh. Üreticiler temel MAC’i basar ve her radyonun MAC’ini bir bayt artırarak türetir, bu yüzden son onaltılık basamak farklıdır; tüm adres yerine öneki karşılaştırın. Ağ geçidinin MAC’i yönlendiricinin LAN arayüzüne aitse düğüm o istemci için yönlendirme yapmıyordur.

Çıkışı yönlendiricide kanıtlayın, hız testiyle değil

Yönlendirici tarafındaki durum, çeviriyi gösteren tek yerdir. OpenWrt’de politika kurallarını ve yönlendirme tablolarını listeleyin, ardından tünelin taze bir handshake’i olduğunu doğrulayın:

ip rule show
ip route show table all | grep default
wg show

pfSense veya OPNsense’de aynı kanıtlar pfctl -sr içinde kurallar için, pfctl -ss içinde etkin durumlar için ve WireGuard durum sayfasında eş sayaçları için bulunur; şu kaynağa göre: WireGuard istemci belgeleri. Durum tablosunu istemcinin adresine göre filtreleyin. Durum istemciyi tünel adresine çevrilmiş gösteriyorsa trafik tünelin içindedir; WAN adresini gösteriyorsa değildir, panodaki rozet ne derse desin.

İstemciden bir traceroute, durum tablosunun veremeyeceği bir gerçeği ekler: ilk atlama. İlk atlama yönlendiricinin LAN adresiyse istemci yönlendiriciye doğrudan ulaşmıştır. Düğümün adresi ve ardından başka bir özel atlama varsa yönlendirilmiş bir segmenttesiniz ve o ikinci atlama politikayı taşıması gereken cihazdır.

Düğümün adres dışında ne dağıttığını kontrol edin

DHCP seçenekleri kiralamayla birlikte gider, bu yüzden kendi DHCP’sini sunan bir düğüm kendi DNS’ini ve kendi IPv6 yönlendirici duyurularını da sunabilir. Bu nedenle bir istemci tünelden çıkıp yine de düğümdeki bir çözümleyiciye sorgu gönderebilir veya tünel politikasının hiç kapsamadığı küresel bir IPv6 adresi alabilir. İkisini de istemcide yazdırın:

cat /etc/resolv.conf
ip -6 addr show scope global

Çözümleyici düğümse ve düğüm yönlendiriciye iletirse DNS tüneli izler. Düğüm yerel olarak çözüyorsa veya sağlayıcının çözümleyicisine işaret ediyorsa sorgular HTTP yapmasa bile tünelin dışına çıkar. IPv6 aynı testi hak eder: küresel bir adres artı tüneli atlayan varsayılan bir yol sızıntıdır ve Mesh ürün yazılımı çoğu zaman IPv6’yı açık bırakırken VPN politikası yalnızca IPv4’ü kapsar.

Tüneli bilerek koparın, sonra sonucu yazın

Tüneli indirin ve o düğüme bağlı bir istemciyi izleyin, yönlendiricinin yanındaki istemciyi değil. ping ve curl kısa zaman aşımıyla yeterlidir; soru trafiğin durup durmadığı veya WAN’a geri düşüp düşmediğidir. Tüneli yönlendiricinin kendi servis komutuyla durdurun, örneğin wg-quick down wg0 veya OpenVPN servisini durdurarak, ve testi kısa tutun.

İstemci çalışmaya devam ediyorsa düğüm veya yönlendirici o segment için açık şekilde başarısız oluyor ve mesh kill switch’i sessizce geri almıştır. Tüneli geri getirin, handshake sayacının hareket ettiğini doğrulayın ve üçüncü adımdaki durum tablosu kontrolünü yineleyin.

Her düğüm için bir satır kaydedin: etiket, SSID, ağ geçidi adresi, MAC öneki, çıkış onaylandı evet veya hayır, IPv6 kapsandı ve tünel kapalıyken davranış. Dolaşma yanıtın değiştiği yerdir, bu yüzden gerçekten kullandığınız odaları test edin. Bir satır diğerleriyle uyuşmadığında incelenmesi gereken düğüm odur ve düzeltme o satırın ağ geçidine sahip cihaza aittir.