Нават ноўтбук за 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

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

Калі форма працуе, запішыце порт, уладальніка і спосаб нагляду побач з канфігурацыяй тунэля. Выпраўленне дасяжнасці, якое існуе толькі ў чыёйсьці гісторыі каманднага радка, у адной перазагрузцы ад паўторнага інцыдэнту.

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