Кліент OpenVPN дасягае сервера, але не хастоў LAN: кантрольны спіс

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

Крок першы: назірайце за рашэннем аб маршрутызацыі кліента

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

ip route get 192.168.50.10

Калі адказ называе ваш фізічны адаптар і офісны шлюз, ніякае змяненне на баку сервера не дапаможа. OpenVPN раздае маршруты толькі тады, калі сервер іх штурхае, таму шукайце push "route 192.168.50.0 255.255.255.0" у канфігурацыі сервера і пасля гэтага перападключыце кліента. Большасць кліентаў прымяняюць праштурханыя маршруты падчас падключэння, а не пры перазагрузцы профілю.

У Windows тое ж пытанне мае іншую каманду. Find-NetRoute -RemoteIPAddress 192.168.50.10 друкуе інтэрфейс і наступны скок, які выбраў бы стек, а route print -4 паказвае, ці існуе праштурханы прэфікс наогул.

Крок другі: пераканайцеся, што сервер будзе перасылаць пакет

Калі маршрут кліента правільны, пакет дасягае сервера, і сервер павінен пагадзіцца яго перасылаць. Пераключальнік ядра — гэта першая брама, і sysctl net.ipv4.ip_forward павінен вярнуць 1. Усталяванне яго праз echo 1 > /proc/sys/net/ipv4/ip_forward працуе да наступнай перазагрузкі, і менавіта таму тая ж скарга вяртаецца праз тыдні.

Запішыце гэта туды, дзе яно перажыве перазагрузку:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Другая брама — гэта табліца фільтраў. Хост з усталяваным Docker часта мае палітыку FORWARD са значэннем DROP, і тунэль наследуе гэтае рашэнне. iptables -L FORWARD -v -n паказвае і палітыку, і лічыльнікі пакетаў; калі палітыка DROP, перасыланне патрабуе яўнага дазволу для кірунку з тунэля ў LAN і асобнага для адказу.

Крок трэці: прасачыце пакет да LAN і шукайце адказ

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

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Запыты, якія з’яўляюцца на tun0 і зноў на eth0 з крыніцай 10.8.0.x, пасля чаго настае цішыня, азначаюць, што пакет прыйшоў, а адказ пайшоў у іншае месца. Хост LAN адказвае свайму шлюзу па змаўчанні, у гэтага шлюзу няма маршруту да пулу VPN, і адказ гіне на маршрутызатары LAN. Пінг хаста LAN з сервера нічога не даказвае пра гэты шлях, бо гэты трафік ніколі не перасякае тунэль.

Крок чацвёрты: выберыце паміж трансляцыяй і зваротным маршрутам

Два рамонты закрываюць дзірку, і выбар мае наступствы за межамі таго, ці працуе ping. Трансляцыя крыніцы робіць сервер выгляданым адпраўніком:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Абмяжуйце правіла пулам і інтэрфейсам LAN, затым зрабіце яго пастаянным, інакш наступная перазагрузка міжсеткавага экрана ціха выдаліць вашае выпраўленне. Кошт — гэта ідэнтычнасць: кожны кліент выглядае як VPN-сервер у журналах LAN і правілах доступу, і per-client policy becomes guesswork.

Статычны маршрут для 10.8.0.0/24 на маршрутызатары LAN, які паказвае на VPN-сервер, пакідае адрасы кліентаў бачнымі і з’яўляецца лепшым доўгатэрміновым адказам, калі гэты маршрутызатар ваш. Шмат пляцовак некаторы час трымаюць абодва: NAT для неадкладнага рамонту і маршрут, як толькі палітыка экрана запісана. Калі сервер — гэта партнёр «пляцоўка-да-пляцоўкі», а не пул, бок сервера таксама патрабуе iroute для аддаленай падсеткі, інакш маршрут партнёра існуе, але трафік кліентаў ніколі з ім не звязваецца.

Крок пяты: праверце з боку кліента і запішыце, што змянілася

Замыкайце цыкл з кліента, а не з сервера. Падключыцеся да рэальнай службы на хосце LAN, затым пацвердзіце, што лічыльнікі трансляцыі зрушыліся, з дапамогай iptables -t nat -L POSTROUTING -v -n, бо правіла з нулём пакетаў — гэта правіла, якое ніколі не супала. conntrack -L -s 10.8.0.5 паказвае паток і яго стан, калі вам патрэбны доказ, што зваротны кірунак адсочваецца.

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