LAN'ınız bir VPN istemcisindeki hizmete neden ulaşamıyor

Bir VPN istemcisi, LAN'ın açamadığı bir hizmeti barındırabilir. Genellikle eksik olan dönüş yoludur: bir rota, bir DNAT çifti ya da kimsenin eklemediği SNAT satırı.

Tüneliniz ayakta, hizmet dinliyor ve ofis LAN'ı hâlâ geri hiçbir şey almıyor. Kimse VPN'i bozmadı. LAN tarafından bakıldığında, dizüstü bilgisayarın tünel adresi, bir şey LAN'a oraya nasıl ulaşacağını söyleyene kadar yoktur ve yanıt, isteğin çıktığı yoldan geri dönmelidir. İnsanların, kimse dönüş yoluna bakmadan önce tamamen sağlıklı bir tüneli üç kez yeniden kurduğunu gördüm.

Bozulan tünel değil

İki uç da özel aralıklarda oturuyor; bu normal durumdur, yanlış yapılandırma değildir. 10.8.0.6 gibi bir adres tünelin içinde gerçektir ve başka hiçbir yerde yoktur, bu yüzden LAN'ın oraya bir şey göndermek için sebebi yoktur. Yönlendirmeye dokunmadan önce hizmetin tünelin içinden erişilebilir olduğunu doğrulayın: istemcide ss -ltn, dinleyicinin 127.0.0.1, LAN arayüzüne mi yoksa tünel adresine mi bağlı olduğunu gösterir. Yalnızca loopback'e bağlı bir daemon kendisinden başkasına yanıt vermez ve hiçbir rota, DNAT ya da port yönlendirmesi bunu değiştirmez.

80 veya 443 portundaki vekil sunucu, farklı görünürlüğe sahip başka bir araçtır. Paketleri değil istekleri taşır, bu yüzden ham veritabanı bağlantısı için yanlış katmandır ve tam da ona uzanmak, bu sorunun birinin bir şey ölçmesinden önce üç araç derinliğe inmesinin yoludur.

Rota biçimi: LAN'a havuzun nerede olduğunu söyleyin

LAN ağ geçidinde statik bir rota, LAN ile tünel havuzu çakışmadığında en temiz yanıttır. Havuzu tüneli sonlandıran makineye yönlendirin:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Bu yalnızca tek yönü düzeltir, bu yüzden bu değişikliğin yarım kalmış sürümleri ilerleme gibi görünür. Tünel tarafının da eşleşen yarıya ihtiyacı var, yoksa yanıt istemciyi kendi varsayılan rotasıyla bırakır ve yolda ölür:

push "route 192.168.1.0 255.255.255.0"

Sunucunun arkasında değil de tek bir istemcinin arkasındaki bir alt ağ için sunucunun hem sistem rotasına hem de o istemcinin dosyasında iroute girdisine (client-config-dir altında) ihtiyacı var. iroute olmadan OpenVPN önekin var olduğunu bilir ve hangi istemcinin ona sahip olduğunu bilmez: paketler gelir ve daemon'un onları eşleştirecek bir şeyi yoktur.

İşte adlandırılmaya değer efsane. Rota bir adresi erişilebilir yapar; karşı tarafı yanıtlamaya istekli yapmaz. Site-siteden eşler üstüne bir katman daha ekler, çünkü uzak ağ geçidi yalnızca politikasında listelenen öneklerin içindeki kaynakları kabul eder ve ev havuzundan gelen bir dizüstü bilgisayar bunların içinde değildir.

NAT biçimi: içeri DNAT ve herkesin atladığı SNAT satırı

LAN ağ geçidine dokunamadığınızda ya da tam olarak bir port yayımlamak istediğinizde, VPN ana bilgisayarındaki çeviri LAN'da hiçbir rota olmadan çalışır. Portu yayımlayın, iletin ve kaynağı tünele giden yolda çevirin:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Üçüncü satır kaybolan satırdır. Atla ve istemci kaynak olarak özgün LAN adresini görür, kendi varsayılan rotasıyla yanıtlar ve o yanıt LAN'a dönmek yerine tünele girer. Bağlantının hayatta kalıp kalmayacağı o zaman hiç planlamadığınız yönlendirmeye bağlı olur. SNAT ile istemci sunucunun tünel adresini görür, böylece yanıt tünelden geri, çeviriyi geri alabilecek tek ana bilgisayara kadar gider.

Tüketici ürün yazılımı kendi zincir adlarını kullanır ve o çeviriyi sizin için üretmez. Tomato'da gelen bir kural WANPREROUTING içine, sonra wanin gibi bir filtre zincirine düşer ve eksiksiz görünen bir kural kümesi yine de elle yazılmış POSTROUTING satırına ihtiyaç duyar. Bu bir ürün yazılımı hatası değil; yalnızca gelen trafik için yazılmış bir kural kümesidir.

Doğru görünen kural neden paketi yine de düşürür

Bu başarısızlıkların çoğu baktığınız kuralda değil. Şu sırayla dört şeyi kontrol edin ve tutmayan ilkinde durun:

  • Zincir sırası. iptables -I en üste ekler, -A sona ekler, bu yüzden daha önceki izin veren ya da engelleyen kural önce karar verir.
  • Yanlış zincir. Yönlendiricinin kendisine adreslenmiş trafik INPUT'tan geçer ve iletilen trafik ona hiç dokunmaz. Tek bir hizmet yayımlamak ikisinde birden kural gerektirebilir.
  • Yön bayrakları. -i tun0 istemcilerden gelen trafikle, -o tun0 onlara giden trafikle eşleşir. Yanlış bayraklı bir REJECT istemediğiniz bir şeyi engeller.
  • Kaynak kısıtlaması. Tek bir istemci adresini kabul eden bir iletim o istemciden çalışır ve diğer her kaynağı tek kelime etmeden düşürür.

Paket sayacı sıfır olan bir kural yolda hiç değildir ve sayaçları okumak, yanlış zincir sorununu yanlış kural sorunundan ayırmanın en hızlı yoludur.

Yerel iletim, LAN'da hiçbir şey değiştirilemediğinde

Yerel SSH iletimi tüm soruyu atlar. LAN'da rotaya, istemcinin güvenlik duvarının işbirliğine ve herhangi bir yerde yayımlanmış porta ihtiyaç duymaz:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Hizmet o zaman tüneli tutan makinenin localhost:3000 üzerinde görünür, başka hiçbir yerde değil. Sınır budur: bir iş istasyonu, bir port ve bir şey yeniden başlatmadıkça iletim oturumla birlikte ölür. Hazırlık veritabanını denetleyen bir yönetici için doğru araçtır. Başka insanların erişmesi gereken bir kamera ya da tarayıcı için değildir, çünkü her kullanıcının kendi iletimine ihtiyacı olurdu.

Bir kural daha eklemeden önce iki yönü de doğrulayın

Çeviri iz bırakır ve onları okumak tahmin etmekten iyidir. VPN ana bilgisayarında conntrack -L çevirinin olup olmadığını, iptables -t nat -L -n -v sayaçların hareket edip etmediğini ve tcpdump -ni any port 3000 hangi kaynak adresin gerçekten geldiğini gösterir. İstemcide ss -ltn dinleyicinin tünelin ulaşabildiği bir adreste olduğunu doğrular.

Sonra tuttuğunuz biçimi seçin. Yayımlanmış tek bir port, tüm havuz için bir rota ve tek bir yönetici için bir iletim üç ayrı taahhüttür ve onları karıştırmak, çalışan bir kurulumun altı ay sonra kimsenin açıklayamayacağı bir kuruluma dönüşmesinin yoludur. Hangi adrese nereden ulaşılabildiğini yazın; bunu ayıklayacak sıradaki kişi tünelle değil yanıtla başlar.

İlgili makaleler