Праграма ў прасторы імёнаў VPN недаступная з LAN

Сеткавая прастора імёнаў дае адной праграме ўласны тунэль і ўласную пятлю. Публікуйце толькі яго порт праз пераход socat або пару veth, а не праз хост.

Ваша служба працуе на машыне, тунэль узняты, а браўзер на вашым стале ўсё яшчэ не атрымлівае адказу. Нічога не зламана ў звычайным сэнсе: праграма слухае унутры сеткавай прасторы імёнаў, і гэты стек нябачны для LAN. Яе пятля належыць прасторы імёнаў, таму кліент на іншай машыне не мае адраса, які дасягае порт. Адзін наўмысны пераход або адна пара veth выпраўляе гэта, не перамяшчаючы рэшту хоста.

Чаму нічога не адказвае на адрасе LAN

Прастора імёнаў — гэта поўны сеткавы стек: інтэрфейсы, маршруты, правілы фаервола і прыватная пятля. Працэс, запушчаны праз ip netns exec, бачыць гэты стек і нічога іншага, таму адрас, які ён прывязвае, развязваецца толькі ўнутры прасторы імёнаў. Уласны 127.0.0.1 хоста — цалкам іншая пятля.

Менавіта таму curl на хосце церпіць няўдачу, а той жа загад унутры прасторы імёнаў выконваецца паспяхова. Праграма здаровая; проста адраса няма ў стэку хоста.

Апублікуйце адзін порт праз пераход socat

socat злучае два стэкі ў прасторы карыстальніка, і гэтага дастаткова, калі праз мяжу павінен прайсці адзіны порт TCP. Бок хоста слухае LAN і для кожнага прынятага злучэння запускае другі socat унутры прасторы імёнаў, які далучаецца да пятлі праграмы. Унутраны працэс дасягае праграмы гэтак жа, як гэта зрабіў бы лакальны кліент. У маршрутызацыі прасторы імёнаў нічога не змяняецца, таму праграма працягвае выкарыстоўваць тунэль як адзіны выхад.

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

Знешняму працэсу патрэбны root або магчымасць увайсці ў прастору імёнаў. Калі VPN абрываецца, праграма губляе шлях, і апублікаваны порт зачыняецца, а менавіта такога паводзінаў вы чакаеце ад турмы.

Выкарыстоўвайце пару veth, калі перасякаецца больш за адзін порт

Пара veth — правільны адказ, калі праз мяжу павінны прайсці некалькі портаў або пратаколаў, альбо калі іншыя хасты павінны ініцыяваць злучэнні. Адзін канец застаецца ў хосце, другі перамяшчаецца ў прастору імёнаў, а невялікая /30 дае абодвум бакам стабільны адрас. Затым маршрут хоста адпраўляе адрас прасторы імёнаў праз пару.

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

Не дадавайце маршрут па змаўчанні праз хост, калі не маеце намеру зламаць турму. Тунэль павінен заставацца выхадам, таму праз пару дасягальны толькі апублікаваны адрас службы. Дайце прасторы імёнаў уласны файл resolver, бо ip netns exec чытае /etc/netns/vpn/resolv.conf, і без яго развязанне імёнаў унутры турмы пустое.

Тэстуйце з іншай машыны, а не з хоста

Запускайце тэст з другой машыны, бо хост можа дасягнуць лакальнага слухача шляхамі, якія нічога не кажуць пра LAN. Спачатку праверце, да чаго праграма насамрэч прывязалася ўнутры прасторы імёнаў, затым падключыцеся да апублікаванага адраса звонку. Прывязка да кожнага адраса там не пашырае турму, бо wildcard усё яшчэ належыць прасторы імёнаў, і LAN не можа яго ўбачыць.

ip netns exec vpn ss -lntp

Калі злучэнне з хоста працуе, а з LAN не, то не хапае пераходу або маршруту, а не адраса прывязкі. Запускайце OpenVPN унутры прасторы імёнаў, а не перамяшчайце туды жывую прыладу tun, бо перамяшчэнне інтэрфейсу выключае яго і можа ачысціць маршруты, якія вы потым не зможаце адрамантаваць звонку. Трымайце каманды аднаўлення на кансолі, а не ўнутры турмы.

Падобныя артыкулы