VPN-nimeruumas olev rakendus pole LAN-ist kättesaadav

Võrgunnimeruum annab ühele programmile oma tunneli ja oma loopbacki. Avalda ainult selle port socat-hüppe või veth-paari kaudu, mitte hosti kaudu.

Teenus töötab masinas, tunnel on püsti, ja ometi ootab töölaual olev brauser ikka veel vastust. Midagi pole tavapärases mõttes katki: rakendus kuulab võrgunnimeruumi sees, ja see virn on LAN-ile nähtamatu. Selle loopback kuulub nimeruumile, seega teises masinas oleval kliendil pole aadressi, mis porti jõuaks. Üks sihilik hüpe või üks veth-paar parandab selle, ilma et ülejäänud hosti liigutaks.

Miks LAN-aadressil miski ei vasta

Nimeruum on täielik võrgupin: liidesed, marsruudid, tulemüürireeglid ja privaatne loopback. ip netns exec kaudu käivitatud protsess näeb seda virna ja mitte midagi muud, seega aadress, millega see liitub, lahendatakse ainult nimeruumi sees. Hosti enda 127.0.0.1 on hoopis teine loopback.

Seetõttu ebaõnnestub curl hostis, samas kui sama käsk nimeruumi sees õnnestub. Rakendus on terve; aadressi lihtsalt pole hosti virnas.

Avalda üks port socat-hüppega

socat sillutab kaks virna kasutajaruumis, millest piisab, kui üle peab minema üksainus TCP port. Hosti pool kuulab LAN-is ja käivitab iga vastuvõetud ühenduse jaoks nimeruumi sees teise socati, mis ühendub rakenduse loopbackiga. Sisemine protsess jõuab rakenduseni täpselt nagu kohalik klient. Nimeruumi marsruutimises ei muutu miski, seega kasutab rakendus tunnelit edasi oma ainsa väljapääsuna.

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

Väline protsess vajab rooti või õigust nimeruumi siseneda. Kui VPN katkeb, kaotab rakendus oma tee ja avaldatud port sulgub, mis ongi käitumine, mida kongist tahad.

Kasuta veth-paari, kui üle läheb rohkem kui üks port

veth-paar on õige vastus, kui üle peab minema mitu porti või protokolli, või kui teised hostid peavad ühendusi algatama. Üks ots jääb hosti, teine liigub nimeruumi, ja väike /30 annab mõlemale poolele stabiilse aadressi. Seejärel saadab hosti marsruut nimeruumi aadressi üle paari.

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

Ära lisa hosti kaudu vaikemarsruuti, kui sa just ei kavatse kongi lõhkuda. Tunnel peab jääma väljapääsuks, seega on üle paari kättesaadav ainult avaldatud teenuse aadress. Anna nimeruumile ka oma resolveri fail, sest ip netns exec loeb /etc/netns/vpn/resolv.conf ja ilma selleta on nimede lahendamine kongi sees tühi.

Testi teisest masinast, mitte hostist

Käivita test teisest masinast, sest host võib jõuda kohaliku kuulajani teid pidi, mis LAN-i kohta midagi ei ütle. Kontrolli kõigepealt, millega rakendus nimeruumi sees tegelikult liitus, ja ühendu seejärel väljastpoolt avaldatud aadressiga. Kõigi aadressidega liitumine seal kongi ei laienda, sest metamärk kuulub endiselt nimeruumile ja LAN ei näe seda.

ip netns exec vpn ss -lntp

Kui hosti ühendus töötab ja LAN-i oma mitte, on puudu hüpe või marsruut, mitte liitumisaadress. Käivita OpenVPN nimeruumi sees, selle asemel et sinna elusat tun-seadet liigutada, sest liidese liigutamine lülitab selle välja ja võib kustutada marsruute, mida sa hiljem väljastpoolt parandada ei saa. Hoia taastamiskäsud konsoolil, mitte kongi sees.

Seotud artiklid