PiVPN el sıkışması çalışıyor, sayfalar takılıyor: MASQUERADE’i kontrol edin

Telefonunuz tüneli bağlı gösteriyor, istemci özel bir adres bildiriyor ve ilk sayfa hâlâ yüklemenin ortasında asılı kalıyor. Bu birleşim çoğu kişiyi şifre ayarlarına ve işlemci sıcaklığına gönderir, oysa gerçekte orada bozuk bir şey yok. Tünel yukarı çıktı, yani görüşme tamamlandı; başarısız olan sonraki adım, sunucu istemci paketlerini internete teslim etmeye çalışırken. O paketlerin izlediği yolu izleyin, uyuşmazlık genellikle NAT tablosunun tek bir satırında görünür.

İstemcinin neye ulaşabildiği ve neye ulaşamadığıyla başlayın

Bağlı istemciden, genel internette bulunan bir sayfa yükleyin ve hemen mi başarısız olduğunu yoksa yarı yolda mı takıldığını not edin. Ardından VPN sunucusunun kendi özel adresindeki bir kaynağı açın ve iki sonucu karşılaştırın.

Genel siteler zaman aşımına uğrarken ping’e yanıt veren bir tünel adresi, yönlendirme veya çeviri sorununun işaretidir, bozuk bir el sıkışmanın değil. İstemcinin kendi durum paneli ikisini ayırt edemez, çünkü yalnızca denetim kanalının ayakta olduğunu bilir. Sunucuda tünel arayüzünü şununla kontrol edin: ip -br addr show tun0 ve istemciye atanan adresin yapılandırdığınız havuzun içinde olduğunu doğrulayın. Havuz ile istemci adresi uyuşmuyorsa önce onu düzeltin, çünkü aşağıdaki her kural havuza göre eşleşir.

Sonra sunucuya genel bir adrese ulaşmak için hangi arayüzü kullanacağını sorun. ip route get 203.0.113.9 ilk satırında seçilen aygıtı ve kaynağı yazdırır. O aygıtın adını not edin, çünkü NAT kuralında bulunması gereken değer odur.

Paketlerin çıkıp çıkmadığına karar veren kuralı okuyun

MASQUERADE bir paketi yalnızca paket kuralda adı geçen arayüzden çıktığında yeniden yazar. Kablolu bir aygıta bağlı kural, Wi-Fi üzerinden çıkan trafik için hiçbir şey yapmaz ve paket özel kaynak adresini üst yönlendiriciye kadar korur. O yönlendiricinin tünel havuzunuza dönüş yolu yoktur, bu yüzden yanıtı düşürür ve istemci açılıp sonra ölen bir bağlantı görür. Belirti, ilk yanıt gerekmeden önce sayfanın ne kadarının geldiğine göre büyür.

Canlı tabloyu listeleyin ve yalnızca MASQUERADE kelimesini aramak yerine çıkış arayüzü sütununu okuyun. Ekleme biçimindeki çıktı, biçimlendirilmiş bir listeye göre karşılaştırması daha kolaydır:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Bir zamanlar Ethernet, şimdi Wi-Fi kullanan bir Raspberry Pi’de eski ad neredeyse her zaman bütün hikâyedir. Kurulum aracı, kurulum sırasında hangi aygıtın bulunduğunu kaydetti ve kayıtlı kural kümesi bunu her açılışta yeniden oynatır. Başka bir şeyi değiştirmeden önce yol aramasından çıkan aygıtı kuraldakiyle karşılaştırın. Eşleşiyorlarsa arayüz sizin sorununuz değildir ve son bölümdeki sayaçlara geçmelisiniz. Farklıysa düzeltme, kalıcılık dosyasındaki tek kelimelik bir değişikliktir.

Kayıtlı kural kümesini düzeltin, yalnızca çalışanı değil

Yalnızca canlı tabloyu düzenlemek bir sonraki yeniden başlatmaya kadar dayanır; bu da sorunun çözüldüğüne sizi ikna etmek için tam olarak yeterlidir. Açılışta geri gelen kurallar, bir güvenlik duvarı kalıcılık paketinin yeniden yüklediği bir dosyada yaşar. Debian tabanlı Pi imajlarında bu dosya genellikle /etc/iptables/rules.v4.

Dokunmadan önce bir kopya alın, sonra MASQUERADE satırındaki çıkış arayüzünü not ettiğiniz aygıtla değiştirin, örneğin -o wlan0 yerine -o eth0. İstemci havuzunuz değişmediyse kaynak aralığını olduğu gibi bırakın. Yeniden yükleyin ve kuralın artık doğru aygıtı belirttiğini doğrulayın:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Yan yana iki ayar kolayca unutulur. sysctl net.ipv4.ip_forward 1 bildirmelidir ve üst yönlendirici özel kaynak adreslerini kendi başına filtrelememelidir.

Kuralın devreye girdiğini kanıtlayın, sonra hâlâ neyin yavaş olduğunu ayırın

Sayaçlar, bir kuralın eşleştiğinin tek dürüst kanıtıdır. Ayrıntılı listeyi çalıştırın, istemcide bir indirme başlatın ve yeniden çalıştırın. Kuralınızın yanındaki paket ve bayt sütunları artmalıdır ve sıfırda kalan bir kural hâlâ eşleşmiyordur. Sayaçlar hareket ediyor ama sayfalar hâlâ başarısız oluyorsa, kaynak aralığını gerçek havuzla şununla karşılaştırın grep -n "^server " /etc/openvpn/server.conf. Hareket ediyor ve sayfalar yükleniyor ama aktarım hızı kötüyse, çeviri tamamlanmıştır ve kalan sorun başka yerdedir.

Aynı istemciden iki aktarımı karşılaştırın: biri yerel ağdaki bir konağa, diğeri tünel üzerinden aynı konağa. Her iki durumda da yavaşsa bu VPN’i değil, Pi’nin üst bağlantısını veya Wi-Fi bağlantısını gösterir. Yalnızca tünel üzerinden yavaşsa bu MTU’yu ve yeniden iletimleri gösterir; bunları şununla inceleyebilirsiniz ip -s link show tun0 herhangi bir şifreleme ayarını değiştirmeden önce.

Deneyi geri almak için kopyayı geri yükleyin ve yeniden yükleyin, ardından özgün kuralın ve sayaçlarının geri döndüğünü doğrulayın. Çıkış aygıtını ve yeniden yükleme komutunu sunucu notlarına yazın, çünkü bir sonraki üst bağlantı değişikliği aynı uyuşmazlığı yeniden keşfedecektir. Yanlış aygıtı belirten bir kural, trafik ona ihtiyaç duyana kadar görünmez kalır.