VPN ad məkanındakı tətbiq LAN-dan əlçatmazdır
Şəbəkə ad məkanı bir proqrama öz tunelini və öz loopback interfeysini verir. Hostun əvəzinə yalnız onun portunu socat atlaması və ya veth cütü ilə yayımlayın.
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.