App binnen in VPN-namromte is net berikber fanôf it LAN

Jo tsjinst wurket op 'e masine, de tunnel is omheech, en dochs wachtet de browser op jo buro noch altyd om antwurd. Der is neat stikken yn 'e gewoane sin: de applikaasje harket binnen in netwurknamromte, en dy stapel is ûnsichtber foar it LAN. Syn loopback heart by de namromte, dat in klant op in oare masine hat gjin adres dat de poarte berikt. Ien bewuste sprong, of ien veth-pear, reparearret dat sûnder de rest fan 'e host te ferpleatsen.

Wêrom't neat antwurdet op it LAN-adres

In namromte is in folsleine netwurkstapel: ynterfaces, rûtes, firewall-regels en in privee loopback. In proses dat fia ip netns exec start wurdt, sjocht dy stapel en neat oars, dat it adres dat it bindt, wurdt allinnich binnen de namromte oplost. De host syn eigen 127.0.0.1 is in hiel oare loopback.

Dêrom mislearret curl op 'e host, wylst itselde kommando binnen de namromte slagget. De applikaasje is sûn; it adres bestiet gewoan net yn 'e stapel fan 'e host.

Publisearje ien poarte mei in socat-sprong

socat oerbrêget de twa stapels yn 'e brûkersromte, wat genôch is as ien inkelde TCP-poarte oerstekke moat. De hostkant harket op it LAN en start foar elk akseptearre ferbining in twadde socat binnen de namromte dy't ferbynt mei de loopback fan 'e applikaasje. It binnenproses berikt de applikaasje krekt sa't in pleatslike klant dat dwaan soe. Neat oan 'e rûtearring fan 'e namromte feroaret, dat de applikaasje bliuwt de tunnel as syn iennichste útgong brûken.

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

It bûtenproses hat root of de mooglikheid nedich om de namromte yn te gean. As de VPN falt, ferliest de applikaasje syn paad en mislearret de publisearre poarte sletten, en dat is it gedrach dat jo fan in finzenis wolle.

Brûk in veth-pear as mear as ien poarte oerstekt

In veth-pear is it goede antwurd as ferskate poarten of protokollen oerstekke moatte, of as oare hosts ferbiningen begjinne moatte. Ien ein bliuwt yn 'e host, de oare ferpleatst nei de namromte, en in lyts /30 jout beide kanten in stabel adres. In hostrûte stjoert dan it adres fan 'e namromte oer it pear.

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

Foegje gjin standertrûte fia de host ta, útsein as jo fan plan binne de finzenis te brekken. De tunnel moat de útgong bliuwe, dat oer it pear is allinnich it publisearre tsjinstadres berikber. Jou de namromte ek syn eigen resolver-triem, want ip netns exec lêst /etc/netns/vpn/resolv.conf en sûnder dat is namme-oplossing binnen de finzenis leech.

Test fan in oare masine, net fan 'e host

Rin de test fan in twadde masine, want de host kin in pleatslike harker berikke fia paden dy't neat oer it LAN sizze. Kontrolearje earst wêr't de applikaasje binnen de namromte echt oan bûn is, en ferbynje jo dan fan bûten mei it publisearre adres. Binen oan elk adres dêr ferbreedet de finzenis net, want it wildcard heart noch altyd by de namromte en it LAN kin it net sjen.

ip netns exec vpn ss -lntp

As de ferbining fan 'e host wurket en dy fan it LAN net, is it ûntbrekkende stik de sprong of de rûte, net it bindadres. Start OpenVPN binnen de namromte ynstee fan in libben tun-apparaat deryn te ferpleatsen, want it ferpleatsen fan 'e ynterface set it út en kin rûtes wiskje dy't jo letter net fan bûten ôf reparearje kinne. Hâld de herstelopdrachten op 'e konsole, net binnen de finzenis.