VPN istemcileri bağlanıyor ama internet yok: üç eksik parça

İstemci bir adres alır, sunucu ping'e yanıt verir ve yine de her sayfa zaman aşımına uğrar. Çoğu kişi bu noktada istemci profilini düzenlemeye başlar, ki bu genellikle boşa emektir: tünel ayakta olduğunda sunucu bir yönlendirici gibi davranmalıdır. Bir paketin çıkıp bir yanıtın dönmesi için üç koşul aynı anda sağlanmalıdır ve hangisi eksik olursa olsun belirti aynıdır.

Çalışan bir tünelin neden hâlâ dışarı çıkışı yok

Çekirdek, paketleri arayüzler arasında iletmelidir; bu çoğu Linux dağıtımında varsayılan olarak kapalıdır. Trafik, dış dünyanın yanıtlayabileceği bir adrese çevrilmelidir; ancak her üst akış yönlendiricisi tünelin alt ağına dönüş yolunu zaten biliyorsa bu gerekmez. Güvenlik duvarının iletim yolu, trafiği yanıtlar dahil iki yönde de geçirmelidir.

Bunlardan her biri ayrı ayrı düzeltilebilir ve tuzak tam da budur. Çeviri kuralı olmadan iletimi açmak, paketlerin özel bir kaynakla ve dönüş yolu olmadan çıkmasına neden olur. İletim kuralı olmadan çeviri eklemek, çekirdeğin paketi bir adım sonra düşürmesine yol açar.

Bu yüzden istemciyi değil üç katmanı test edin ve sonucun bir anlamı olsun diye her seferinde birini değiştirin.

İletim, kalıcı hale getirmeniz gereken bir çekirdek anahtarıdır

Değiştirmeden önce mevcut değeri kontrol edin, ardından ayarlayın ve değişikliğin yürürlüğe girdiğini doğrulayın.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

İlk komut mevcut değeri bildirir, ikincisi çalışma zamanında ayarlar, üçüncüsü ise yazmanın işe yaradığını kanıtlar. Çalışma zamanı değeri bir sonraki yeniden başlatmada kaybolur; bu yüzden çalışan bir oturum, herhangi bir yapılandırma değişikliği olmadan bakımdan sonra bozulabilir.

/etc/sysctl.d/ altındaki bir dosyada kalıcı hale getirin, sonra öğrenmek için yeniden başlatmak yerine o dosyayı uygulayın. FreeBSD'de eşdeğeri net.inet.ip.forwarding'tir ve kalıcılık için rc.conf içinde gateway_enable=YES kullanılır. İletimin kapalı olduğunu bildiren bir cihaz, «paketler geliyor ve hiçbir şey geri dönmüyor» türünden bütün bir rapor sınıfını açıklar. Her yükseltmeden sonra da ayarı kontrol edin, çünkü yeniden derlenmiş bir çekirdek veya değiştirilmiş bir cihaz imajı kimseye söylemeden onu sıfırlayabilir.

masquerade veya tek bir sabit çeviri adresi seçin

Dinamik bir dış adresle masquerading en basit doğru biçimdir. Tünelin alt ağını kaynak, dış arayüzü çıkış olarak adlandırın.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Statik bir genel adresle kaynağın tam olarak o adrese çevrilmesi daha öngörülebilir ve denetlemesi daha kolaydır.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

İkinci biçim bir bakım tuzağı taşır: sonradan değişen sabit kodlanmış bir adres, tüneli çalışır tutarken internet erişimi sessizce durur. Ya masquerade kullanın ya da sağlayıcı sizi taşıdığında kuralı güncelleyin. Arayüz de önemlidir, çünkü kendi üst akış tünelini paylaşan bir yönlendirici fiziksel WAN üzerinden değil, o tünel üzerinden çeviri yapmalıdır.

Filtre tablosu üçüncü kapıdır

İletim ve çeviri ikisi de doğru olabilirken paket yine de filtre tablosunda ölür. ufw sık sık suçludur: iletim politikası DROP olarak gelir ve o tek ayar trafiği öldürürken kurulumun geri kalanı tamamen doğru görünebilir. Onu yükseltmek bir onay kutusu değil, bilinçli bir güvenlik kararıdır.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

İlk kural tünelden dışarıya yeni trafiğe izin verir, ikincisi yalnızca yanıtların geri dönmesine. İkisini de tünelin alt ağına ve amaçlanan hedefe daraltın, çünkü tünel arayüzünde genel bir izin VPN'i kimlik doğrulayabilen herkes için açık bir çıkış noktasına dönüştürür.

Köprülenmiş bir tünel farklı bir yanıt gerektirir. Adres fiziksel porta değil köprüye aittir, bu yüzden arayüzü köleye çevirmek eskiden sahip olduğu adresi kaldırır ve köprü kendisi bir adres alana kadar ana makine erişilemez görünür; bunu dhclient br0 sağlayabilir. Bu arıza VPN sorunu gibi görünür ama ikinci katman sorunudur. Güvenlik duvarına dokunmadan önce köprünün kendi adresini kontrol edin, çünkü filtre değişikliği artık gönderecek adresi olmayan bir ana makineyi onaramaz.

Bir sayfa hiç yüklenmediğinde nereye bakmalı

Tünelin var olduğunu kanıtlamak için sunucunun tünel adresine ping atın. Ardından istemciden genel bir adrese traceroute çalıştırın ve nerede durduğunu okuyun: sunucuda paket ulaşır ama iletilmez veya çevrilmez; sunucunun ötesinde sorun üst akıştadır ve sizin elinizde değildir.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

İlk komut tünelin trafiği sunucunun kendisine taşıdığını kanıtlar, ikincisi bir paketin dışarıya ne kadar ulaştığını gösterir. Tünel adresinde biten bir iz sunucudaki iletim veya çevirime işaret ederken, bir atlama sonra duran bir iz sağlayıcıya veya üst akış yönlendiricisinin dönüş yoluna işaret eder.

Sunucuda, bir istemci sayfa yüklerken dış arayüzü izleyin. Özel kaynak adresiyle çıkan trafik çevirinin eksik olduğunu, hiç yanıt olmaması ise iletim yolunun veya üst akış dönüş yolunun onu düşürdüğünü gösterir.

Uzak istemciler sunucunun LAN'ındaki ana makinelere de ulaşmalıysa, LAN'ın tünelin alt ağına dönüş yoluna ihtiyacı olduğunu unutmayın. Bu çeviri değil yönlendirmedir ve internet yolu nihayet çalıştıktan sonra en sık unutulan adımdır.