VPN ad alanındaki uygulamaya LAN'dan erişilemiyor

Hizmetiniz makinede çalışıyor, tünel açık, ama masanızdaki tarayıcı hâlâ yanıt bekliyor. Olağan anlamda hiçbir şey bozuk değil: uygulama bir ağ ad alanının içinde dinliyor ve o yığın LAN için görünmez. Loopback'i ad alanına ait, bu yüzden başka bir makinedeki istemcinin porta ulaşan bir adresi yok. Tek bir bilinçli atlama ya da tek bir veth çifti, ana makinenin geri kalanını taşımadan bunu düzeltir.

Neden LAN adresinde hiçbir şey yanıt vermiyor

Bir ad alanı eksiksiz bir ağ yığınıdır: arayüzler, yollar, güvenlik duvarı kuralları ve özel bir loopback. ip netns exec ile başlatılan bir süreç yalnızca o yığını görür ve başka hiçbir şeyi görmez, bu yüzden bağlandığı adres yalnızca ad alanının içinde çözülür. Ana makinenin kendi 127.0.0.1 adresi tamamen farklı bir loopback'tir.

Bu yüzden curl ana makinede başarısız olurken aynı komut ad alanının içinde başarılı olur. Uygulama sağlıklı; adres yalnızca ana makinenin yığınında yok.

Tek portu socat atlamasıyla yayımlayın

socat iki yığını kullanıcı uzayında köprüler, tek bir TCP portunun geçmesi gerektiğinde bu yeterlidir. Ana makine tarafı LAN'da dinler ve kabul edilen her bağlantı için ad alanının içinde uygulamanın loopback'ine bağlanan ikinci bir socat başlatır. İç süreç uygulamaya tam olarak yerel bir istemcinin yapacağı gibi ulaşır. Ad alanının yönlendirmesinde hiçbir şey değişmez, bu yüzden uygulama tüneli tek çıkışı olarak kullanmaya devam eder.

socat TCP-LISTEN:9100,reuseaddr,fork EXEC:'ip netns exec vpn socat STDIO tcp-connect:127.0.0.1:9100',nofork

Dış sürecin root ya da ad alanına girme yeteneğine ihtiyacı vardır. VPN düşerse uygulama yolunu kaybeder ve yayımlanan port kapalı olarak başarısız olur, bir hücreden beklediğiniz davranış da budur.

Birden fazla port geçtiğinde veth çifti kullanın

Birden fazla port veya protokolün geçmesi gerektiğinde ya da başka ana makinelerin bağlantı başlatması gerektiğinde veth çifti doğru yanıttır. Bir uç ana makinede kalır, diğeri ad alanına geçer ve küçük bir /30 iki tarafa da kararlı bir adres verir. Ardından ana makine yolu ad alanının adresini çift üzerinden gönderir.

ip link add veth0 type veth peer name veth1
ip link set veth1 netns vpn
ip addr add 10.77.0.1/30 dev veth0
ip link set veth0 up
ip netns exec vpn ip addr add 10.77.0.2/30 dev veth1
ip netns exec vpn ip link set veth1 up

Hücreyi kırmayı düşünmüyorsanız ana makine üzerinden varsayılan yol eklemeyin. Tünel çıkış olarak kalmalı, bu yüzden çift üzerinden yalnızca yayımlanan hizmet adresine ulaşılabilir. Ad alanına kendi çözümleyici dosyasını da verin, çünkü ip netns exec /etc/netns/vpn/resolv.conf dosyasını okur ve o olmadan hücre içindeki ad çözümlemesi boştur.

Ana makineden değil, başka bir makineden test edin

Testi ikinci bir makineden çalıştırın, çünkü ana makine yerel bir dinleyiciye LAN hakkında hiçbir şey söylemeyen yollardan ulaşabilir. Önce uygulamanın ad alanı içinde gerçekte neye bağlandığını kontrol edin, sonra dışarıdan yayımlanan adrese bağlanın. Orada her adrese bağlanmak hücreyi genişletmez, çünkü joker karakter hâlâ ad alanına aittir ve LAN onu göremez.

ip netns exec vpn ss -lntp

Ana makineden gelen bağlantı çalışıp LAN'dan gelen çalışmıyorsa eksik parça bağlanma adresi değil, atlama ya da yoldur. Çalışan bir tun aygıtını içeri taşımak yerine OpenVPN'i ad alanının içinde başlatın, çünkü arayüzü taşımak onu kapatır ve sonra dışarıdan onaramayacağınız yolları temizleyebilir. Kurtarma komutlarını hücrenin içinde değil konsolda tutun.