Апликација во VPN именски простор е недостапна од LAN

Вашата услуга работи на машината, тунелот е подигнат, а сепак прелистувачот на вашата маса сѐ уште чека одговор. Ништо не е расипано во вообичаената смисла: апликацијата слуша внатре во мрежен именски простор, и тој стек е невидлив за LAN. Нејзиниот loopback ѝ припаѓа на именскиот простор, затоа клиент на друга машина нема адреса што стигнува до портата. Еден намерен скок или еден veth пар го поправа тоа без да го премести остатокот од домаќинот.

Зошто ништо не одговара на LAN адресата

Именскиот простор е целосен мрежен стек: интерфејси, рути, правила за огнен ѕид и приватен loopback. Процесот стартуван преку ip netns exec го гледа само тој стек и ништо друго, затоа адресата кон која се врзува се решава само внатре во именскиот простор. Сопствената 127.0.0.1 на домаќинот е сосема друг loopback.

Затоа curl на домаќинот не успева, додека истата наредба внатре во именскиот простор успева. Апликацијата е здрава; адресата едноставно не постои во стекот на домаќинот.

Објавете еден порт со socat скок

socat ги премостува двата стека во корисничкиот простор, што е доволно кога треба да помине еден TCP порт. Страната на домаќинот слуша на LAN и за секоја прифатена врска стартува втор socat внатре во именскиот простор што се поврзува со loopback-от на апликацијата. Внатрешниот процес ја достигнува апликацијата точно како што би сторил локален клиент. Ништо во рутирањето на именскиот простор не се менува, затоа апликацијата продолжува да го користи тунелот како единствен излез.

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. Прво проверете кон што апликацијата навистина се врзала внатре во именскиот простор, потоа поврзете се однадвор на објавената адреса. Врзувањето на сите адреси таму не го проширува затворот, бидејќи џокерот сѐ уште му припаѓа на именскиот простор и LAN не може да го види.

ip netns exec vpn ss -lntp

Ако врската од домаќинот работи, а од LAN не, делот што недостига е скокот или рутата, а не адресата на врзување. Стартувајте OpenVPN внатре во именскиот простор наместо да преместувате таму жива tun направа, бидејќи преместувањето на интерфејсот ја исклучува и може да избрише рути што потоа нема да можете да ги поправите однадвор. Држете ги командите за враќање на конзолата, а не внатре во затворот.