Programo en VPN-nomspaco neatingeblas el la LAN

Retnomspaco donas al unu programo sian propran tunelon kaj sian propran loopback. Publikigu nur ĝian pordon per socat-salto aŭ veth-paro anstataŭ per la gastiganto.

Via servo funkcias sur la maŝino, la tunelo staras, kaj tamen la retumilo sur via tablo ankoraŭ senrezulte atendas. Nenio estas difektita laŭ la kutima senco: la aplikaĵo aŭskultas ene de retnomspaco, kaj tiu stako estas nevidebla por la LAN. Ĝia loopback apartenas al la nomspaco, do kliento sur alia maŝino ne havas adreson, kiu atingas la pordon. Unu intenca salto, aŭ unu veth-paro, riparas tion sen movi la reston de la gastiganto.

Kial nenio respondas ĉe la LAN-adreso

Nomspaco estas kompleta retstako: interfacoj, itineroj, fajroŝirmaj reguloj kaj privata loopback. Procezo lanĉita per ip netns exec vidas tiun stakon kaj nenion alian, do la adreso, al kiu ĝi ligiĝas, solviĝas nur ene de la nomspaco. La propra 127.0.0.1 de la gastiganto estas tute alia loopback.

Tial curl sur la gastiganto malsukcesas, dum la sama komando ene de la nomspaco sukcesas. La aplikaĵo estas sana; la adreso simple ne ekzistas en la stako de la gastiganto.

Publikigi unu pordon per socat-salto

socat pontas la du stakojn en uzantspaco, kio sufiĉas kiam unu sola TCP-pordo devas transiri. La gastiganta flanko aŭskultas en la LAN kaj, por ĉiu akceptita konekto, lanĉas duan socat ene de la nomspaco, kiu konektiĝas al la loopback de la aplikaĵo. La interna procezo atingas la aplikaĵon ĝuste kiel loka kliento farus. Nenio pri la enkursigado de la nomspaco ŝanĝiĝas, do la aplikaĵo daŭre uzas la tunelon kiel sian solan eliron.

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

La ekstera procezo bezonas root aŭ la kapablon eniri la nomspacon. Se la VPN falas, la aplikaĵo perdas sian vojon kaj la publikigita pordo malsukcesas fermite, kio estas la konduto, kiun vi volas de karcero.

Uzu veth-paron kiam pli ol unu pordo transiras

veth-paro estas la ĝusta respondo kiam pluraj pordoj aŭ protokoloj devas transiri, aŭ kiam aliaj gastigantoj devas iniciati konektojn. Unu fino restas en la gastiganto, la alia moviĝas en la nomspacon, kaj malgranda /30 donas al ambaŭ flankoj stabilan adreson. Gastiganta itinero tiam sendas la adreson de la nomspaco tra la paro.

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

Ne aldonu defaŭltan itinero tra la gastiganto krom se vi intencas rompi la karceron. La tunelo devas resti la eliro, do tra la paro atingeble estas nur la publikigita serva adreso. Donu al la nomspaco ankaŭ sian propran solvan dosieron, ĉar ip netns exec legas /etc/netns/vpn/resolv.conf kaj sen ĝi la nomosolvado ene de la karcero estas malplena.

Testu de alia maŝino, ne de la gastiganto

Rulu la teston de dua maŝino, ĉar la gastiganto povas atingi lokan aŭskultanton per vojoj, kiuj diras nenion pri la LAN. Unue kontrolu, al kio la aplikaĵo fakte ligiĝis ene de la nomspaco, poste konektiĝu de ekstere al la publikigita adreso. Ligiĝi al ĉiu adreso tie ne larĝigas la karceron, ĉar la ĵokero ankoraŭ apartenas al la nomspaco kaj la LAN ne povas vidi ĝin.

ip netns exec vpn ss -lntp

Se la konekto de la gastiganto funkcias kaj tiu de la LAN ne, la mankanta peco estas la salto aŭ la itinero, ne la liga adreso. Lanĉu OpenVPN ene de la nomspaco anstataŭ movi vivan tun-aparaton en ĝin, ĉar movi la interfacon malŝaltas ĝin kaj povas forviŝi itinerojn, kiujn vi poste ne povas ripari de ekstere. Tenu la riparajn komandojn sur la konzolo, ne ene de la karcero.

Rilataj artikoloj