Tam tünelli OpenVPN: sunucu tarafına bir internet çıkışı ekleyin

Bir istemci kimliğini doğrular, havuzdan bir adres alır ve VPN ana bilgisayarındaki hizmetlere ulaşır, ancak her genel hedef zaman aşımına uğrar. Çıkışı olmayan bir tünel böyle görünür ve dört ayrı şey doğru olana kadar böyle kalır. İstemci varsayılan bir rotayı kabul etmeli, sunucu iletmeli, güvenlik duvarı geçişe izin vermeli ve yanıtların havuza dönüş yolu olmalıdır. Dört arıza da tek bir belirtiyi paylaşır, bu yüzden her denemede tek bir öğeyi değiştirin ve sonucu not edin.

Varsayılan rotayı itin ve istemcinin ne kurduğunu doğrulayın

Sunucu tarafındaki satır kısadır ve yalnızca itilen seçenekleri kabul eden istemcileri etkiler. def1 biçimi mevcut varsayılanı silmek yerine iki yarım varsayılan rota kurar; bu, geçerli bağlantıyı canlı tutarken her hedefi yine de yakalar.

push "redirect-gateway def1"

Yeniden bağlandıktan sonra profile güvenmek yerine istemcinin yönlendirme tablosunu okuyun. Linux'ta iki /1 girdisi özgün varsayılanın yanında görünür ve Windows aynı çifti 0.0.0.0/1 ve 128.0.0.0/1 olarak gösterir. İtilen seçenekleri yok sayan ya da bunları reddetmek üzere yapılandırılmış bir istemci eski varsayılanını korur ve internet trafiğini asla tünele göndermez. Sunucuda herhangi bir şeyi değiştirmeden önce bu soruyu çözün, çünkü sunucu tarafındaki hiçbir kural bunu telafi edemez.

İletme bir sunucu ayarıdır, VPN ayarı değil

Yönlendirmeye dokunmadan önce iletme bayrağını okuyun. Oradaki sıfır, çekirdeğin istemcinin paketini alıp iletmeyi reddettiği anlamına gelir; bu, uzak uçtan bakıldığında tam olarak bir güvenlik duvarı engeli gibi görünür. Değeri sistemin yapılandırma dizini üzerinden ayarlayın ki yeniden başlatmadan sonra da kalsın.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Ardından, ana bilgisayarın kendisinin internet çıkışına giden çalışan bir rotası olduğunu doğrulayın. Sunucunun kabuğundan yapılan bir istek, yukarı akış yolunun kullanılabilir olduğunu kanıtlar ve bir istemcinin paketini iletmek hakkında hiçbir şey söylemez, bu yüzden bunları iki ayrı test olarak ele alın. Sunucu hedefe ulaşamıyorsa hiçbir miktarda iletme yapılandırması yardımcı olmaz.

Tam olarak amaçladığınız geçişe izin verin, başka hiçbir şeye değil

İletilen paketler forward yolundan geçer; VPN ana bilgisayarının kendisine yönelen trafik input yolundan geçer. Bunlar farklı kararlardır ve input yolunu açmak makineden geçişe izin vermez. İkisini karıştırmak, bir güvenlik duvarının her şeye izin veriyormuş gibi görünürken istemcilerin hâlâ zaman aşımına uğramasının en yaygın nedenidir.

Asgari politika, havuzdan çıkış arayüzüne doğru yeni bağlantıları kabul eder ve kurulmuş akışlara ait yanıtları kabul eder. Her açılışta yinelenen bir kural eklemek yerine, dağıtımınızın kullandığı kural kümesi sahibine koyun; yinelenen kurallar birikir ve sayaçlar bir anlam ifade etmez olur.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Her zinciri kabul olarak değiştirmek testi geçirir ve güvenlik duvarının var olma nedenini ortadan kaldırır. Kapsamı havuz ve çıkış arayüzünde tutun, ilgisiz iletmeyi kendi hâline bırakın.

Yanıtlara gidecek bir yer verin

Havuz adresleri özeldir, bu yüzden genel bir sunucu onlara doğrudan yanıt teslim edemez. Ya VPN ana bilgisayarı çıkışta kaynak adresi çevirir ya da yukarıdaki bir cihaz havuza dönüş rotası tutar.

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

Tam olarak bir çeviri katmanı ekleyin. Daha yukarıdaki ikinci bir NAT birincisini gizler ve sonradan bir şey bozulduğunda iki günlüğü de neredeyse işe yaramaz hâle getirir. Yukarıdaki yönlendirici havuzu zaten geri yönlendiriyorsa, ana bilgisayarda çeviri eklemek gereksizdir ve dönüş yolu o zaman sizinkine değil o yönlendiricinin yapılandırmasına bağlıdır.

Bulut örnekleri bir kapı daha ekler, çünkü bazı platformlar kaynak adresi örneğin kendisine ait olmayan paketleri bu denetim gevşetilmedikçe düşürür. Bu ayar konuğun dışındadır ve yerel bir test makinesi çalıştığında unutulması kolaydır.

Bunu sunucunun kabuğundan değil, istemciden kanıtlayın

Sayısal bir IPv4 isteğiyle başlayın, sonra bir ad çözümlemesi, sonra uygulama. ping iletmeyi ve çeviriyi kanıtlar;ad çözümlemesi hakkında hiçbir şey kanıtlamaz, çünkü DNS seçenekleri ancak istemci tümleşimi bunları kurduğunda yürürlüğe girer.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Değişiklikleri ve geri alma adımını ilerledikçe not edin, böylece bir test başarısız olduğunda çıkış politikası tek bir eylemle geri alınabilsin. Bu tarif yalnızca IPv4'ü kapsar; dağıtımın tüm trafiği taşıdığını iddia etmeden önce IPv6'yı ayrıca envanterleyin.