Чаму ваша LAN не можа дасягнуць сэрвісу на кліенце VPN

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

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

Тунель не зламаўся

Абодва бакі сядзяць у прыватных дыяпазонах, і гэта нармальны выпадак, а не памылка канфігурацыі. Адрас накшталт 10.8.0.6 рэальны ўнутры тунеля і не існуе нідзе больш, таму LAN не мае прычыны нешта туды слаць. Перш чым кранаць маршрутызацыю, пераканайцеся, што сэрвіс наогул дасягальны ўнутры тунеля: на кліенце ss -ltn паказвае, ці прывязаны слухач да 127.0.0.1, да інтэрфейсу LAN або да адраса тунеля. Дэман, прывязаны толькі да loopback, адказвае толькі сабе, і ніякі маршрут, DNAT або пракід партоў гэтага не зменіць.

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

Форма маршруту: скажыце LAN, дзе знаходзіцца пул

Статычны маршрут на шлюзе LAN — самы чысты адказ, калі LAN і пул тунеля не перакрываюцца. Накіруйце пул на машыну, якая завяршае тунель:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

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

push "route 192.168.1.0 255.255.255.0"

Для падсеткі, якая знаходзіцца за адным кліентам, а не за серверам, серверу патрэбны і сістэмны маршрут, і запіс iroute у файле гэтага кліента ў client-config-dir. Без iroute OpenVPN ведае, што прэфікс існуе, і не мае ўяўлення, які кліент ім валодае: пакеты прыходзяць, а дэману няма з чым іх супаставіць.

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

Форма NAT: DNAT унутр і радок SNAT, які ўсе прапускаюць

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

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

Спажывецкая прашыўка выкарыстоўвае ўласныя назвы ланцугоў і не стварае гэтую трансляцыю за вас. На Tomato правіла для ўваходу трапляе ў WANPREROUTING, а затым у ланцуг фільтрацыі накшталт wanin, і набор правілаў, які выглядае поўным, усё роўна патрабуе ручнога радка POSTROUTING. Гэта не памылка прашыўкі; гэта набор правілаў, напісаны толькі для ўваходнага трафіку.

Чаму правільнае на выгляд правіла ўсё роўна скідае пакет

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

  • Парадак ланцугоў. iptables -I устаўляе ў пачатак, а -A дадае ў канец, таму ранейшае дазваляльнае або блакіруючае правіла вырашае першым.
  • Няправільны ланцуг. Трафік, адрасаваны самому роўтару, праходзіць праз INPUT, а перанакіраваны трафік яго ніколі не кранае. Публікацыя аднаго сэрвісу можа патрабаваць правілаў у абодвух.
  • Сцягі кірунку. -i tun0 супастаўляе трафік, які прыходзіць ад кліентаў, а -o tun0 — трафік, які ідзе да іх. REJECT з няправільным сцягам блакіруе тое, чаго вы не мелі на ўвазе.
  • Абмежаванне крыніцы. Перанакіраванне, якое прымае адзін адрас кліента, працуе ад гэтага кліента і скідае любую іншую крыніцу без слова.

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

Лакальнае перанакіраванне, калі на LAN нічога нельга змяніць

Лакальнае перанакіраванне SSH абынае ўсё пытанне. Яму не патрэбны ні маршрут на LAN, ні супрацоўніцтва фаеруола кліента, ні порт, апублікаваны дзе-небудзь:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Сэрвіс тады з’яўляецца на localhost:3000 машыны, якая трымае тунель, і нідзе больш. Вось мяжа: адна працоўная станцыя, адзін порт, і перанакіраванне памірае разам з сеансам, калі нешта яго не перазапусціць. Для адміністратара, які правярае тэставую базу даных, гэта правільны інструмент. Для камеры або сканера, да якіх павінны дабрацца іншыя людзі, — не, бо кожнаму карыстальніку спатрэбілася б сваё перанакіраванне.

Праверце абодва кірункі, перш чым дадаваць яшчэ адно правіла

Трансляцыя пакідае сляды, і чытанне іх лепш за здагадкі. На хасту VPN conntrack -L паказвае, ці адбылася трансляцыя наогул, iptables -t nat -L -n -v паказвае, ці зрушыліся лічыльнікі, а tcpdump -ni any port 3000 паказвае, які адрас крыніцы сапраўды прыйшоў. На кліенце ss -ltn пацвярджае, што слухач знаходзіцца на адрасе, дасягальным праз тунель.

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

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