Uzak kullanıcılar VPN merkezi üzerinden ikinci siteye ulaşamıyor

Uzak bir kullanıcı merkeze bağlanır, merkezin kendi LAN'ındaki dosya sunucusuna ulaşır ve her şey sağlıklı görünür. Sonra genel merkezdeki 10.20.0.50 üzerindeki paylaşımı açar; merkez oraya ayrı bir site-sitedan-site tüneliyle ulaşır ve istek zaman aşımına uğrar. İki tünel de ayakta ve iki sayaç da artıyor, yani hiçbir tünel bozuk değil. Merkezden geçmek üç cihazda üç yönlendirme kararıdır, ve tünel yalnızca kendisi için kurulduğu önekleri taşır. İşte kontrol ettiğim sıra ve her adımın doğru olup olmadığını gösteren komut.

Geçiş üç arama gerektirir, tek bir tünel değil

Her cihaz kendi en uzun önek eşleşmesini yapar ve unutur. Dizüstü 10.20.0.50'yi yerel yönlendiricisine değil tünele göndermelidir. Merkez, uzak erişim arayüzüne gelen paketi alıp site-sitedan-site arayüzüne vermelidir. Genel merkez, kullanıcının adresine yönelik yanıtı tünel üzerinden geri göndermelidir. Bu üçünden herhangi birinin başarısızlığı tarayıcıda aynı görünür: sessizlik.

Bu yüzden her tüneli tek başına test etmek çok az şey kanıtlar. Merkezin LAN adresine ping atmak ilk kararı çalıştırır, genel merkezden merkeze ping atmak üçüncüyü çalıştırır. Başarısız olan paketin kaynağı kullanıcı havuzu, hedefi ikinci sitedir, bu yüzden önce o önekleri yazın. Burada havuz 10.80.0.0/24, merkezin LAN'ı 10.10.0.0/24 ve genel merkez 10.20.0.0/24.

Uzak öneki uzak istemciye itin

Bir OpenVPN uzak erişim sunucusunda istemci rotaları bağlanma anında öğrenir. push olmadan, bölünmüş tünelli bir istemci 10.20.0.50'yi kendi ağ geçidine gönderir ve paket tünele hiç girmez.

push "route 10.20.0.0 255.255.255.0"

İtilen rota istemci bağlandığında yürürlüğe girer, bu yüzden çevrimiçi kalan kullanıcı yeniden bağlanana kadar hiçbir şey görmez. İstemcide doğrulayın: Linux'ta ip route get 10.20.0.50, Windows'ta route print. Çıktı tünel arayüzünü adlandırmalıdır.

push merkeze yardımcı olmaz. Bu istemciye bir mesajdır, sunucuda bir rota değildir ve iletme izni de değildir, bu yüzden kusursuz bir push satırına sahip merkez bile akışı bir sıçrama sonra düşürür. İnsanların push başarısız oldu sonucuna varmasının olağan nedeni budur.

Merkeze gerçek bir çıkış rotası verin

Merkezin genel merkez öneki için kendi sonraki sıçramasına ihtiyacı var. Yönlendirilen bir tünelde bu, site-sitedan-site arayüzünden geçen sıradan bir rotadır ve tek bir komut hem seçilen rotayı hem seçilen kaynağı gösterir:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Site-sitedan-site bacağı kendisi OpenVPN ise, rota o yapılandırmada eşin tünel adresini ağ geçidi olarak alarak yaşayabilir: route 10.20.0.0 255.255.255.0 172.30.0.2. Ağ geçidi isteğe bağlı değildir. Onu atlarsanız sonraki sıçrama uygulamanın varsayılanına düşer, bu da tek uzak noktalı bir istemci ile çok eşli bir merkez arasında farklıdır.

Politika tabanlı IPsec farklıdır: merkezin çekirdeği paketi normal LAN ağ geçidine gönderir ve politika onu çıkışta yakalar, bu yüzden tünel rotası ya hiçbir şey yapmaz ya da trafiği politikanın dışına yönlendirir. Yukarıdaki komutta kaynağa dikkat edin, çünkü havuz adresi yerine 10.10.0.1 olması çekirdeğin uzak tarafın reddedeceği bir adres seçtiği anlamına gelir. iroute de yanıt değildir; sunucuya hangi istemcinin kendi tünelinin arkasındaki alt ağa sahip olduğunu söyler, üçüncü site için trafiğin nereye gönderileceğini değil.

Uzak tarafı kullanıcı havuzuna kadar genişletin

Genel merkez merkezin LAN'ını, 10.10.0.0/24'ü zaten kapsıyor. Kullanıcı havuzu ikinci bir önektir ve seçicilerde de olmalıdır, yoksa hiçbir politika 10.80.0.25'e yönelen bir yanıtı kapsamaz. Her eş aynı önek kümesi çiftini kendi tarafından adlandırır:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Bir cihazın local_ts'si diğerinin remote_ts'sidir. Merkezin bloğunu genel merkeze kopyalayın ve çift ters döner, bu yüzden alt SA hiçbir zaman ayağa kalkmaz.

Daha eski ipsec.conf sözdizimi virgülle ayrılmış leftsubnet kullanır. Çalışan güvenlik ilişkisi müzakere ettiği seçicileri korur, bu yüzden düzenlemeden sonra tüneli yeniden kurun. 10:00'da değiştirilen bir seçici 09:40'ta ayağa kalkan bir SA'ya karşı test edildiğinde hâlâ başarısız olur, oysa yapılandırma dosyası baştan sona doğru görünür.

Sonra son sıçramayı kontrol edin. Uzak uçtaki ip route get 10.80.0.25 tünele işaret etmelidir. Hizmet LAN yönlendiricisini varsayılan ağ geçidi olarak kullanıyorsa, o yönlendiricinin de dönüş rotasına ihtiyacı vardır, yoksa yanıt orada ölür. O segmentte tcpdump -ni eth1 host 10.80.0.25 çalıştırmak yanıtın uçtan çıkıp çıkmadığını gösterir.

Merkezde akışa izin verin

İletme etkin ve yol izinli olmalıdır. Arayüzler arasında her şeyi kabul etmek yerine kuralları iki önekle sınırlayın.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Ters yol filtreleme yanındaki sessiz arızadır: iki bacak farklı arayüzlerdeyken rp_filter=1 yanıtı düşürebilir, oysa kabul kuralının sayacı hiç hareket etmez. Bir denemeden önce ve sonra iptables -vnL FORWARD karşılaştırın. Hiç artmayan bir kurala ulaşılmıyor demektir, bu yüzden onu yeniden yazmak yerine bir katman aşağı bakın.

Yalnızca bir grup geçişe ihtiyaç duyuyorsa, genel push'u genişletmek yerine rotayı client-config-dir altında istemci başına bir dosyaya koyun. Merkezdeki Source NAT da uzak tarafta dönüş rotası ihtiyacını ortadan kaldırır, ancak kullanıcının adresini gizler, bu yüzden uzak sitenin günlükleri ve adres tabanlı kurallar kullanıcıları ayırt etmeyi bırakır.

İstemciden doğrulayın, sonra ters sırayla geri alın

Yalnızca ICMP değil, bir TCP bağlantı noktasını test edin, çünkü ping geçerken hizmet engelli kalabilir. İstemciden nc -vz 10.20.0.50 445 ve traceroute -n 10.20.0.50 ikinci sıçramanın merkezin tünel adresi olup olmadığını gösterir. Merkezde tcpdump -ni tun0 host 10.20.0.50 ve site-sitedan-site arayüzünde aynı filtre: ikisinde de istek ama hiçbirinde yanıt yoksa sorun uzak tarafa taşınır.

Sonra engelli kalması gereken bir şeyi test edin. Havuzun asla ulaşmaması gereken bir ana bilgisayar da yanıt veriyorsa geçişten fazlasını açtınız ve kuralları daraltmalısınız. Her şeyi her kola ileten merkez ilk testi geçer ve ikincisinde başarısız olur.

Bir geri alma listesi tutun, çünkü dört nesne değişti ve üçü kolayca unutulur: itilen rota, merkezin rotası, seçiciler ve güvenlik duvarı kuralları. Bunları ters sırayla geri alın, SA'yı yeniden kurun ve bir kullanıcının yeniden bağlanmasına izin verin. Kısmi bir geri alma, artık eşleşmeyen bir tünele işaret eden bir rota bırakır ve bunu okumak özgün sessizlikten daha zordur. OpenVPN 2.6 kılavuzu sürümünüz için push, route ve iroute belgeler.