Xidmətiniz maşında işləyir, tunel qalxıb, amma masanızdakı brauzer hələ də cavab almır. Adi mənada heç nə pozulmayıb: tətbiq şəbəkə ad məkanının içində dinləyir və bu yığın LAN üçün görünməzdir. Onun loopback-i ad məkanına aiddir, ona görə başqa maşındakı klientin portu çatan ünvanı yoxdur. Bir qəsdli atlama və ya bir veth cütü, hostun qalan hissəsini tərpətmədən bunu düzəldir.

Niyə LAN ünvanında heç nə cavab vermir

Ad məkanı tam şəbəkə yığınıdır: interfeyslər, marşrutlar, firewall qaydaları və şəxsi loopback. ip netns exec vasitəsilə başladılan proses yalnız bu yığını görür, buna görə bağlandığı ünvan tək ad məkanının daxilində həll olunur. Hostun öz 127.0.0.1 ünvanı tamamilə başqa loopback-dir.

Buna görə hostda curl uğursuz olur, halbuki eyni əmr ad məkanının içində uğur qazanır. Tətbiq sağlamdır; sadəcə ünvan hostun yığınında mövcud deyil.

Bir portu socat atlaması ilə yayımlayın

socat iki yığını istifadəçi sahəsində birləşdirir və tək TCP portunun keçməsi lazım olduqda bu kifayətdir. Host tərəfi LAN-da dinləyir və qəbul edilən hər bağlantı üçün ad məkanının içində tətbiqin loopback-inə qoşulan ikinci bir socat başladır. Daxili proses tətbiqə elə çatır ki, sanki yerli klientdir. Ad məkanının marşrutlaşdırmasında heç nə dəyişmir, ona görə tətbiq tuneli yeganə çıxışı kimi istifadə etməyə davam edir.

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

Xarici prosesə root və ya ad məkanına daxil olmaq imkanı lazımdır. VPN düşərsə, tətbiq yolunu itirir və yayımlanan port bağlanmış vəziyyətdə sıradan çıxır; qəfəsdən istədiyiniz davranış budur.

Birdən çox port keçəndə veth cütündən istifadə edin

Bir neçə port və ya protokol keçməlidirsə, ya da digər hostlar bağlantı başlatmalıdırsa, veth cütü düzgün cavabdır. Bir ucu hostda qalır, digəri ad məkanına keçir və kiçik bir /30 hər iki tərəfə sabit ünvan verir. Sonra host marşrutu ad məkanının ünvanını cütün üzərindən göndərir.

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

Qəfəsi dağıtmaq niyyətiniz yoxdursa, hostdan keçən standart marşrut əlavə etməyin. Tunel çıxış olaraq qalmalıdır, ona görə cütün üzərindən yalnız yayımlanan xidmət ünvanı əlçatandır. Ad məkanına öz resolver faylını da verin, çünki ip netns exec /etc/netns/vpn/resolv.conf faylını oxuyur və o olmadan qəfəsin içində ad həlli boş qalır.

Hostdan deyil, başqa maşından sınaqdan keçirin

Testi ikinci maşından işlədin, çünki host yerli dinləyiciyə LAN haqqında heç nə deməyən yollarla çata bilər. Əvvəlcə tətbiqin ad məkanının içində həqiqətən nəyə bağlandığını yoxlayın, sonra kənardan yayımlanan ünvana qoşulun. Orada hər ünvana bağlanmaq qəfəsi genişləndirmir, çünki wildcard hələ də ad məkanına aiddir və LAN onu görə bilmir.

ip netns exec vpn ss -lntp

Host bağlantısı işləyirsə və LAN bağlantısı işləmirsə, çatışmayan hissə bağlanma ünvanı deyil, atlama və ya marşrutdur. Canlı tun cihazını ora köçürmək əvəzinə OpenVPN-i ad məkanının içində başladın, çünki interfeysi köçürmək onu söndürür və sonra kənardan bərpa edə bilməyəcəyiniz marşrutları silə bilər. Bərpa əmrlərini qəfəsin içində deyil, konsolda saxlayın.

Əlaqəli məqalələr