OpenVPN üzerinden genel önek: dönüş yolunu düzeltin

Tünelin açıldığını ve istemcinin karşı tarafa ping attığını izleyin, sonra VPN'in arkasında olması gereken genel bir adres başka bir yerden yanıt verir ya da hiç yanıt vermez. Bu belirtinin genellikle şifreleme veya sertifikalarla ilgisi yoktur. Sağlayıcının yönlendirdiği önek bir IP yolu olarak teslim edilir ve onu OpenVPN üzerinden taşımak, bu yolu iki düzeyde yeniden üretmek ve dönüş yolunda kaynak adresini korumak anlamına gelir. WAN'ı köprülemek gerekmez ve adresi bir arayüze eklemek üst yolu oluşturmaz.

Önek önce size yönlendirilmelidir

Sağlayıcıya bloğun nasıl teslim edildiğini sorun. Sunucunuzun ana adresine yönlendirilen bir önek, sağlayıcının bir WAN segmentinde doğrudan ulaşmayı beklediği adreslerden farklı bir şeydir. Buradaki tasarımla yalnızca ilk model çalışır.

Sağlayıcı 198.51.100.64/28'i giriş sunucunuza yönlendiriyorsa, o aralığın paketleri sunucuya ulaşır ve siz onları iletmediğiniz sürece orada durur. Sağlayıcı bunun yerine aralığı uplink'inize köprülüyorsa, sunucu bunun için ARP yanıtı vermelidir, bu başka bir sorundur.

OpenVPN'e dokunmadan önce teslimat modelini test edin: dışarıdan bloktaki bir adrese ping atın ve hangi arayüzün onu aldığını görün. Hiçbir şey gelmiyorsa hiçbir tünel yapılandırması yardımcı olmaz. Adres WAN'da doğrudan yanıt veriyorsa, sağlayıcı yönlendirmek yerine köprülüyor ve aşağıdaki tasarım geçerli değil.

İki yönlendirme düzeyi: çekirdek yolu ve iroute

OpenVPN öneğe iki yerde ihtiyaç duyar. Çekirdek, öneğin tünel aygıtına ait olduğunu bilmelidir, böylece iletilen paketler varsayılan yol yerine OpenVPN'e girer. OpenVPN ayrıca hangi kimliği doğrulanmış istemcinin öneğe sahip olduğunu bilmelidir ve bu, istemciye özgü dizindeki iroute kaydıdır.

Sunucu tarafındaki yol şöyle görünür, önek ve maskenin tahsise uyması gerekir:

ip route add 198.51.100.64/28 dev tun0

İstemciye özgü yapılandırma sahipliği atar. Bunu istemci sertifikasının ortak adıyla adlandırılmış CCD dosyasına koyun ve sunucunun gerçekten okuduğu dizinin o olduğunu doğrulayın:

iroute 198.51.100.64 255.255.255.240

OpenVPN'in yönlendirilmiş ağlar hakkındaki belgeleri iki düzeyi ve neden ayrı olduklarını açıklar. iroute olmadan çekirdek yolu paketleri sahipsiz olarak tünele gönderir ve OpenVPN onları atar. Çekirdek yolu olmadan iroute paketleri sunucunun varsayılan yolunda bırakır. Her iki hata da istemci tarafından bozuk bir tünel gibi görünür.

Hizmet adresi nerede yaşar

Devredilen önek tünelin kendi adresleriyle aynı şey değildir. İsterseniz bağlantıyı özel alandan numaralandırın ve genel hizmet adresini hizmetin gerçekten çalıştığı yere koyun.

Hizmeti yerel olarak sonlandıran bir Linux istemcisinde tek bir ana bilgisayar adresi yeterlidir:

ip address add 198.51.100.70/32 dev lo

Önek bir VM ana bilgisayarına veya başka bir LAN'a yönlendirilirse, bunun yerine o aşağı akış yolunu ve dönüş yolunu yapılandırın. Bloktaki her adresi VPN istemcisine atamak gerekli değildir ve daha sonra çakışmalar yaratır.

Genel kaynağı dönüş yolunda koruyun

Devredilen önekten gelen yanıt tünelden çıkmalı ve sağlayıcının yoluna ulaşmalıdır. Uzak ana bilgisayar bunu kendi ISP'si üzerinden gönderirse, kaynak adresi sahte görünür ve sağlayıcı ya da hedef onu atar. Çözüm kaynağa dayalı bir kural veya özel bir yönlendirme tablosudur, daha geniş bir NAT değil. O olmadan hizmet tünel eşinden çalışır ve diğer her yerden başarısız olur.

Giriş sunucusunda geniş bir masquerade kuralı olağan suçludur. Genel kaynağı sunucunun ana adresine yeniden yazar ve istemci gerçek olanı asla görmez:

iptables -t nat -S POSTROUTING

NAT'ı buna ihtiyaç duyan özel VPN istemcileriyle sınırlayın ve devredilen öneği çevrilmemiş bırakın. Ardından sunucunun öneği hiç iletip iletmediğini doğrulayın, çünkü varsayılan olarak reddeden bir iletme zinciri onu sessizce atar.

Güvenmeden önce iki yönü de doğrulayın

Doğrulama bir değil dört gözlemdir. Sağlayıcının yolunun geldiğini, çekirdeğin öneği tünele gönderdiğini, OpenVPN'in onu doğru istemciye atadığını ve yanıtın genel kaynak sağlam dönerek geldiğini doğrulayın. Her gözlemin kendi komutu vardır, bu nedenle bir arıza tüm tasarımı değil bir katmanı gösterir. Her yapılandırma değişikliğinden sonra bunları bu sırayla çalıştırın.

Çekirdeğe devredilen bir adresin hangi yolu izlediğini sorun ve bir istek çalışırken tüneli izleyin:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Ters yol filtreleme doğru bir yolu geçersiz kılabilir. Tüneldeki ve uplink'teki etkin ayarı kontrol edin ve katı modun kaynağı geldiği arayüzle eşleşmeyen trafiği reddettiğini unutmayın:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Son olarak arıza durumunu test edin. Tüneli durdurun ve genel öneğin olağan uplink'ten sızmadığını doğrulayın. VPN'i geri yüklemek, ana bilgisayarın açtığı bağlantı noktalarını genişletmeden hizmeti geri getirmelidir.