Чак и преносни рачунар иза NAT-а провајдера може услужити колегу, ако VPN сервер служи као место сусрета. Тамо воде два механизма: клијент се повезује напоље и тражи од сервера да држи порт за слушање, или сервер објављује порт и преводи га у тунел. Оба решавају исти проблем доступности и понашају се различито при квару, надзору и евидентирању. Три услова одређују који од њих припада вашој конфигурацији.

Два облика, једно место сусрета

У првом облику клијент отвара SSH сесију напоље и тражи од сервера да слуша на изабраном порту, враћајући сваку везу назад кроз ту сесију. На серверу се ништа не прослеђује и не долази до превода пакета, па су једини захтеви SSH налог, дозвољено прослеђивање и правило заштитног зида за порт. Услуга остаје везана за loopback на клијенту, што је обично оно што желите.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

У другом облику јавни порт поседује сервер и преписује сваку везу према адреси тунела клијента. То захтева укључено IP прослеђивање, превод одредишта на улазу и превод извора на излазу, и наставља да ради када нема SSH сесије. Порт припада серверу, а не сесији, и управо то својство одлучује у већини реалних случајева.

Ниједан облик није безбеднији по конструкцији. Оба на крају излажу један порт услуге свакоме ко може да достигне јавну адресу сервера, и оба и даље зависе од сопствене аутентификације услуге.

Услов први: мора ли порт да живи дуже од сесије

Обрнуто прослеђивање живи тачно онолико колико SSH сесија која га је створила. Када веза падне, слушалац нестаје и колега види одбијену везу уместо спорог пута. Надзор над командом уз systemd јединицу и политику поновног покретања то решава, а ExitOnForwardFailure=yes чини неуспешно повезивање одмах видљивим уместо да остави сесију без прослеђивања.

Преведени порт преживљава поновна покретања ако су правила сачувана, али зависи од тога да клијент задржи исту адресу тунела. Динамички базен који преносном рачунару после поновног повезивања даје другу адресу тихо усмерава правило у ништа. Прво резервишите адресу тунела, затим напишите правило, и третирајте обоје као једну измену.

Ако услуга мора да одговори у три сата ујутру без икога да гледа, облик са портом који сервер објављује има мање покретних делова, јер једини процес који мора да остане покренут јесте сам тунел.

Услов други: чији су заштитни зид и евиденције

Обрнути облик држи целу политику на два места. sshd преко AllowTcpForwarding одлучује да ли су удаљена прослеђивања уопште дозвољена, а GatewayPorts одлучује да ли се слушалац везује за loopback или за сваку адресу. Са подразумеваном вредношћу no колега ван сервера не може да достигне порт иако је прослеђивање успело, и то изгледа као покварен тунел када је у ствари реч о адреси везивања.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

Преведеном облику потребно је укључено прослеђивање и два правила, а друго правило је место где већина рецепата греши. Ограничавање превода извора на стање conntrack DNAT значи да се преписују само везе које је створило правило одредишта, уместо сваког пакета који сервер пошаље у тунел.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

То преписивање уништава и приписивање. После тога клијент види сваког позиваоца као адресу тунела сервера, што све лимите брзине по адреси спаја у једну канту и скрива ко је шта послао. Ако је приписивање важно, завршите везу на серверу или тамо задржите одлуку о дозволи и проследите идентитет у заглављу којем услуга верује. Избор између ове две поправке зависи од тога да ли услуга уопште чита прокси заглавље.

Услов трећи: један порт или много, и чије је име

Једна услуга на једном порту је случај у којем обрнуто прослеђивање побеђује по труду. Потребни су вам једна команда, један налог и једно правило заштитног зида, а чишћење је убијање сесије. Више услуга на истој јавној адреси гура вас ка облику који сервер објављује, јер је сваком обрнутом прослеђивању потребан сопствени серверски порт и скуп расте са сваком услугом.

Имена то додатно компликују. Обрнуто прослеђивање може стајати иза TCP проксија који усмерава по SNI, док је преведени порт обично један порт по услузи. Ако услуга сама завршава TLS и потребно јој је изворно име домаћина, приступ са проксијем га чува, а приступ са DNAT га чува само ако услуга прихвата то име на том порту.

Запишите који је од три услова одредио облик. Иначе ће следећа особа која дода другу услугу поново отворити исто поређење са мање контекста.

Одлучите, затим тестирајте споља

Тестирајте пут из мреже која нема никакву руту до преносног рачунара, и посматрајте бројаче на серверу док се захтев извршава. Тестирање са сервера ка његовој сопственој јавној адреси овде ништа не доказује, јер се пакет ствара локално и никада не стиже до куке за превод улаза, па тест може проћи док је стварни пут покварен.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

Бројачи који остају равни значе да пакет никада није стигао до правила, што указује на провајдера или заштитни зид домаћина. Бројачи који се померају док услуга одбија указују на сопствени заштитни зид клијента или на адресу на којој услуга слуша. Тунел који преноси пакет али не враћа ништа је проблем руте или повратног пута, и ниједан од ова три исхода не треба отклањати уређивањем адаптера клијента. Запишите који се бројач померио пре него што било шта промените, јер следећем тесту треба та основна линија.

Када облик проради, запишите порт, власника и метод надзора поред конфигурације тунела. Поправка доступности која постоји само у нечијој историји љуске удаљена је једно поновно покретање од поновљеног инцидента.

Повезани чланци