OpenVPN'e bağlı ama hiçbir şey yüklenmiyor: istemciden dışarı doğru bir yürüyüş

İstemci penceresi Connected diyor, tünel adresi orada ve tarayıcı hâlâ dönüyor. Bu bileşim normaldir, çünkü başarılı bir el sıkışma yalnızca tünelin kurulduğunu kanıtlar; sunucunun paketlerinizi iletip iletmeyeceğini, kaynağını yeniden yazıp yazmayacağını veya DNS sorgularınıza yanıt verip vermeyeceğini söylemez. Çoğu kişinin hatası önce sunucu yapılandırmasını açmaktır. Bunun yerine istemciden dışarı doğru çalışın, çünkü aşağıdaki her adım bir sonrakinin kontrol edilmeye değer olup olmadığını söyler.

İstemcide başlayın ve dışarı doğru ilerleyin

Bu sırayla üç test yapın ve ilkinin nerede başarısız olduğunu yazın. Sunucunun tünel adresine ping atın; bu, tünelin kendisinin trafik taşıdığını kanıtlar. Bir genel adrese numarayla ping atın; bu, ad çözümlemesini işe katmadan iletmeyi ve çeviriyi kanıtlar. Sonra bir ana bilgisayar adını çözmeyi deneyin; DNS kullanan tek test budur. Her sonuç şüpheden bütün bir katmanı çıkarır.

Tarayıcı daha hızlı hissettiriyor diye üçüncü teste atlamayın. Başarısız bir sayfa yüklemesi üç katmanı birden kapsar ve insanlar tam oradan başlayıp sonra çalışan bir tüneli yeniden kurar. Başarısız sayfa üçünden hangisinin bozulduğunu söylemez.

İki yakalama paketlerin nerede durduğunu gösterir

İstemciden bir genel adrese ping akarken tünel arayüzünde bir, internete çıkması gereken üst bağlantıda bir yakalama alın. Zaman damgaları örtüşsün diye ikisini aynı anda çalıştırın.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

İstekler tünelde görünüp üst bağlantıda hiç görünmüyorsa sunucu onları tünel ile kablo arasında düşürmüştür ve neden iletme veya iletme için güvenlik duvarı politikasıdır, NAT değil. İkisinde de görünüyorsa sunucu kendi payını yapmıştır ve yanıt daha dışarıda kaybolmuştur; bu çeviriye, yukarıdaki bir filtreye veya sağlayıcı tarafındaki bir kısıtlamaya işaret eder.

Üst bağlantının adını eğitimden değil yönlendirme tablosundan alın. Bulut imajları ve yeniden adlandırılmış bağdaştırıcılar bir kılavuzdaki örnek arayüzle nadiren eşleşir ve yanlış aygıtta alınan yakalama tam olarak iletmeyen bir sunucu gibi görünür:

ip -4 route get 9.9.9.9

O çıktıdaki dev alanı NAT kuralının sonra ihtiyaç duyacağı addır, bu yüzden onu saklayın.

İletme bir çekirdek anahtarı ve bir güvenlik duvarı politikasıdır

Çekirdek baştan iletmeyi kabul etmelidir. Geçerli değeri okuyun, sonra ayarı yalnızca çalışan çekirdeğe yazmak yerine kalıcı hale getirin:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

İletme işin yalnızca yarısı. UFW kullanan bir ana makinede iletme politikası /etc/default/ufw içinde ayarlanır ve yeniden yükleme etkili olmadan önce ACCEPT olmalıdır. İletme yolundaki varsayılan düşürme, el sıkışmayı tamamen sağlıklı bırakırken tünelden çıkmaya çalışan her paketi sessizce atar ve bu tam olarak başladığınız belirtidir.

nftables'ı doğrudan yöneten ana makineler aynı soruyla başka bir sözdiziminde karşılaşır. İstemci testi çalışırken iletme zincirindeki sayaçlara bakın, çünkü danışılan zincir ile düşüren zincir bir yapılandırma dosyasında aynı görünür.

NAT kuralında gerçek çıkış arayüzünü adlandırın

Kaynak çevirisi ana makineyi gerçekten terk eden arayüze aittir, sunucunun dağıttığı havuzla birlikte. Bu kuralın iki yarısı da gerçeği tanımlamalıdır ve hiçbiri isteğe bağlı değildir.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Klasik başarısızlık, bir kılavuzdan kopyalanan ve bağdaştırıcısı başka ad taşıyan bir makinede -o eth0 diyen kuraldır. Kural uyarı vermeden kurulur, hiçbir şeyle eşleşmez ve istemcinin hâlâ interneti yoktur. Havuz da aynı hatanın diğer yarısıdır: sunucu 10.44.0.0/24 dağıtıyorsa ve kural 10.8.0.0/24 kapsıyorsa hiçbir şey asla eşleşmez.

Kural metnine güvenmek yerine sayaçlara bakın. Liste her kural için paket bildirir ve hiç eşleşmeyen kural ne kadar doğru görünürse görünsün sıfırda kalır. O sayıdan bir şey okumadan önce ona bir dakika gerçek istemci trafiği verin:

iptables -t nat -L POSTROUTING -v -n

Gerçek bir istemci testinden sonra sıfır paket sayısı eşleşmenin yanlış olduğu anlamına gelir, tünelin bozuk olduğu değil. Eşleşmeye başladığında kural kümesini kaydedin ki yeniden başlatmaya dayansın; yalnızca kabuk geçmişinizde yaşayan bir düzeltme ilk yeniden başlatmada kaybolur.

Sunucu aynı zamanda bir bulut NAT örneğiyse platformun da sözü vardır. Adresleri çeviren bir örnek genellikle sağlayıcının bu ayarı sunduğu yerde kaynak ve hedef denetiminin kapatılmasını gerektirir ve VPN bağlantı noktasının kendisi dışarıdan erişilebilir olmalıdır.

DNS, ilkinin arkasındaki ikinci başarısızlıktır

Adresle ping çalışırken adların başarısız olması bir çözümleyici sorunudur, ve kendi nedeni vardır. Yerel çözümleyicisini koruyan bir istemci bu sorguları tam bir tünele gönderir ve asla gelmeyen bir yanıtı bekler, çünkü yerel çözümleyici artık rotanın yanlış tarafındadır.

İstemcinin nereden soracağını bilmesi için sunucudan bir çözümleyici itin. İki girdi, ilki erişilemezse istemciye bir yedek verir ve ikisi de tünelin gerçekten izin verdiği çözümleyiciler olmalıdır.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows istemcileri yine de yerel çözümleyiciye geri düşebilir, block-outside-dns tam olarak bunu önlemek için vardır, ama yalnızca yerel ağın çözebildiği adları kaybetme pahasına. systemd-resolved kullanan Linux istemcileri bir betik kurmadıkça itilen çözümleyiciyi sıklıkla yok sayar, bu yüzden itmenin yok sayıldığı sonucuna varmadan önce tünel aygıtı için resolvectl status'a bakın.

Yürüyüşü bir kullanıcının deneyimlediği gibi bitirin. İstemciden gerçek bir sayfa yükleyin, hangi adresten çıktığını doğrulayın, sunucuyu yeniden başlatın, yeniden bağlanın ve üç testi yineleyin. Yalnızca o ikinci tur, kaydedilen kuralların, güvenlik duvarı politikasının ve itilen çözümleyicinin hepsinin birlikte hayatta kaldığını kanıtlar.