Siteden siteye VPN yanıtı tünelden geçmiyor

Bir sabahı temiz kalkan ve trafiği tam olarak tek yönde taşıyan bir tünelde geçirdim: şube merkezdeki dosya sunucusuna ulaşabiliyordu ve merkezden şubeye açılan her bağlantı ilk SYN'de ölüyordu. SA'lar ayaktaydı, tünel sayaçları artıyordu ve el sıkışma hiçbir zaman sorun değildi. Yanıt, tünelin kapsamadığı bir yere yönlendiriliyordu ve bu seçim uzak tarafa aittir. Siteden siteye VPN yalnızca bir ana bilgisayarın ağ geçidine verdiği paketleri taşır ve her ana bilgisayar bu seçimi ayrı ayrı, her yönde, kendi yönlendirme tablosundan yapar.

İki yön ayrı ayrı yönlendirilir

IP bir konuşmanın yönünü hatırlamaz. Paket gönderen her ana bilgisayar kendi en uzun önek aramasını yapar, bir sonraki atlamayı seçer ve kararı unutur. İstek ve yanıt, aynı bağlantıya tesadüfen ait olan iki ilgisiz pakettir ve tünel, ikisinden herhangi birinin kullanabileceği ya da kullanmayabileceği tek bir atlamadır. IKE alışverişinde hiçbir şey uzak sunucuya alt ağınıza nasıl ulaşacağını öğretmez; müzakere yalnızca hangi öneklerin şifrelenebileceği konusunda anlaşır.

Bu anlaşma ikinci kapıdır. strongSwan'da trafik seçicileri leftsubnet ve rightsubnet'dir ve kaynağı veya hedefi anlaşılan çiftin dışına düşen bir paket, yönlendirme tablosu ne derse desin şifrelenmez. Tünele yönlendirilen ama seçicilerde bulunmayan bir önek sessiz tek yönlü bir arızadır: rota doğru görünür, paket yine de açık olarak çıkar veya düşürülür ve yalnızca charon günlüğü şikayet eder.

Uzak ana bilgisayar tüneliniz hakkında hiçbir şey bilmez

Uzak LAN içinde yanıt, istemcinize adreslenmiş sıradan bir pakettir. Hedef ana bilgisayar hiçbir IPsec başlığı görmez ve VPN ağ geçidini tercih etmek için bir nedeni yoktur; önekinizi arar, varsayılan rotasından daha belirgin bir şey bulamaz ve onu izler. Varsayılan bir çekirdek güvenlik duvarına işaret ediyorsa, duvarın tünele geri dönen bir rotası vardır ya da yoktur. Yoksa sessiz bir düşürme, bir ICMP unreachable ya da internet tarafındaki arayüzden çıkıp ölen bir yanıt alırsınız.

Rota olsa bile ikinci bir arayüz bunu bozmaya yeter. Başka bir VLAN'da yönetim bağlantısı olan bir NAS, yedek uplink'i olan bir sunucu, bir kaynak aralığını ikinci tabloya gönderen bir ilke kuralı: bunlardan herhangi biri yanıtı yakalayabilir. Linux'ta ip rule show ve ip route show table all, varsayılan listenin gizlediği kuralları ve tabloları gösterir.

Kararı yanıtı gönderen makinede okuyun

Bir şeyi değiştirmeden önce çekirdeğe sorun ve ona kaynak adresini verin, çünkü kaynağa bağlı kurallar yanıtı değiştirir.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Çıktı, giden arayüzü ve sonraki atlamayı adlandırır. Arayüz VPN ağ geçidine bakan arayüz değilse kusuru buldunuz ve geriye rotanın nereye ait olduğunu seçmek kalır. Ağ geçidinden yapılan ping burada az şey kanıtlar: uzak ana bilgisayarın yerleştirebileceği bir adresle yanıt verir, dizüstü bilgisayarınızın adresiyle değil.

Windows'ta karşılıklar karar için Find-NetRoute -RemoteIPAddress 10.10.5.10 ve tablo için Get-NetRoute'dır. Varsayılandan daha yüksek metrik taşıyan New-NetRoute ile eklenen rota sessizce kaybeder, bu yüzden girişi değil metrik sütununu okuyun. Sonra paketlerle doğrulayın: uzak LAN arayüzünde tcpdump -ni any "host 10.10.5.10 and tcp port 445" isteği gösterir ve tünel tarafındaki aynı filtre bir yanıtın dönüp dönmediğini gösterir. İstek görünüyor ama yanıt yoksa yanıt başka yere yönlendirilmiş veya düşürülmüştür; yanlış arayüzdeki bir yanıt, rotaya dokunmadan önce size suçluyu verir.

Sunucunun ağ geçidi VPN uç noktası olmadığında

Birçok site sunucularla yoğunlaştırıcı arasına bir güvenlik duvarı koyar. O duvar yanıtı iletir, bu yüzden istemci önekiniz için VPN ağ geçidine bakan bir rotaya ve iki yönde iletme ilkesine ihtiyacı vardır. Durum tutan cihazlar işi kötüleştirir: istek duvarı izin verdiği bir LAN ana bilgisayarından geçti, yanıt artık başka bir yönden geliyor ve bağlantı izleme girdisi artık eşleşmiyor, bu yüzden paket reddedilmek yerine geçersiz sayılarak düşürülür. Trafik kaybolurken ilke günlüğünün boş görünmesinin nedeni budur.

Ağ geçidinin kendi ikinci filtresi vardır. Linux'un ters yol filtrelemesi, kaynağına geldiği arayüzden ulaşılamayan paketleri düşürür ve bu tam olarak meşru asimetrik bir dönüş yolunun şeklidir. strongSwan'ın iletme kılavuzu tam da bu nedenle net.ipv4.ip_forward ve gevşetilmiş bir net.ipv4.conf.all.rp_filter ister. Herhangi bir ağ geçidindeki katı 1 değeri doğru bir rotayı sessizce bozar ve nereye bakacağınızı biliyorsanız nstat -az düşürmeleri gösterir.

Yönlendirin ya da çevirin, sonra iki yönde doğrulayın

İki onarım eşdeğer değildir. Rota eklemek istemci adresini olduğu gibi bırakır, böylece kaynak tabanlı kurallar, denetim günlükleri ve arayanı kaydeden uygulamalar çalışmaya devam eder; bedeli, kararı veren her atlamanın rotaya ihtiyaç duyması, yani hata yapılacak daha çok yer olmasıdır. Uzak ağ geçidinde maskeleme dönüş yolunu tek bir atlamaya sıkıştırır, çünkü yanıt artık ağ geçidinin kendisine adreslenmiştir, ve hangi istemcinin ne yaptığını saklar.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Bunu bilerek seçin: istemciler ağ geçidinin adresi olarak görünmeye başladığında, kaynak tabanlı ACL'ler onları ayırt edemez ve yanıtın tünele geri yazılması için conntrack eşlemeyi tutmak zorundadır. Seçiciler istemci önekini hâlâ dışlıyorsa NAT hiçbir şeyi değiştirmez, çünkü istek tünele hiç girmemiştir.

Düzeltildi demeden önce dört şeyi sırayla doğrulayın: yanıtı gönderen ana bilgisayardaki rota, onu ileten her atlamadaki rota, iki öneki kapsayan seçiciler ve yanıtın beklediğiniz kaynakla tünele girdiğini gösteren bir kayıt. Sonra testi diğer siteden tekrarlayın. Tek yönün geçmesi yarı açık bir tasarımdır ve ikinci yön genellikle az önce onardığınızdan farklı bir nedenle başarısız olur.