Ці трэба рабіць SNAT для перакідання порта ў падсетку VPN?

Перакіданне порта на хост, які знаходзіцца за ўласным VPN-кліентам маршрутызатара, правальваецца так, што выглядае як праблема фаервала, бо запыт відавочна даходзіць. Сэрвіс рэгіструе злучэнне, кліент чакае, і нічога не вяртаецца. Трансляцыя пункту прызначэння зрабіла сваю справу; зваротны пакет — гэта тое, што знікла. Адно выбарачнае правіла SNAT на маршрутызатары выпраўляе гэта, і цікавае тут — вырашыць, наколькі вузкім можа быць гэтае правіла.

Чаму адказ ідзе іншай дарогай

Перакіданне порта перапісвае, куды ідзе пакет, але ніколі — адкуль ён прыйшоў. Адрас інтэрнэт-кліента застаецца ў полі крыніцы на ўсім шляху праз тунель, таму аддалены сэрвіс бачыць незнаёмца і адказвае адзіным вядомым яму спосабам: праз свой шлюз па змаўчанні. Гэты шлюз — канцэнтратар VPN на далёкім баку, у якога няма маршруту назад да адвольнага публічнага адраса.

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

Правіла крыніцы, дастаткова вузкае, каб давяраць

Зрабіце маршрутызатар крыніцай, на якую адказвае аддалены хост. У гэтай схеме адрас WAN — 203.0.113.24, LAN — 192.168.88.0/24, адрас тунеля маршрутызатара — 172.20.5.1, а сэрвіс адказвае на 172.20.5.40:8443. Правіла ніжэй супадае з пакетам пасля трансляцыі пункту прызначэння, таму яно называе трансляваны адрас, а не публічны. Нішто ў ім не залежыць ад адраса кліента, і менавіта ў гэтым сутнасць.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

Калі суцэльная маскіроўка — сумленны выбар

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

Дзве опцыі і правальваюцца па-рознаму. Адсутнае вузкае правіла ламае адну паслугу; шырокая маскіроўка, якая супадае з лішнім, можа ціха перапісаць трафік, які ўжо працаваў, уключаючы ўласныя зыходныя злучэнні маршрутызатара.

Праверце лічыльнікі перад публікацыяй

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

Нулявы лічыльнік на правіле крыніцы пасля рэальнага злучэння азначае, што супадзенне няправільнае, звычайна таму, што пункт прызначэння або порт не адпавядае пакету пасля трансляцыі. Калі лічыльнік расце, але кліент усё яшчэ выходзіць па тайм-ауце, зваротны шлях выпраўлены, і нешта іншае скідае адказ, таму далей паглядзіце на палітыку перакідання на далёкім баку. Доступ праз пятлю знутры LAN — асобная праблема, і ёй патрэбна сваё правіла, а не шырэйшая версія гэтага.