Кліент VPN з маршрутызацыяй дасягае сервера, але не хастоў LAN

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

Ідзіце за адказам, а не за запытам

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

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

Змясціце зваротны маршрут там, дзе глядзяць хасты

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

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

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Чаму NAT крыніцы выглядае як выпраўленне

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

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

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Хмарны шлях патрабуе трох налад

У VPC той жа прагал вяртаецца ў іншай форме, бо падсетка зусім не мае маршруту для дыяпазону кліентаў. Табліцы маршрутызацыі патрэбны запіс для пула тунэля, які накіраваны на сеткавы інтэрфейс інстанса, а інтэрфейсу трэба адключыць праверку крыніцы і прызначэння, каб платформа прымала пакеты, крыніца якіх не з'яўляецца яго ўласным адрасам. Групы бяспекі і сеткавыя ACL таксама павінны пускаць пул у абодвух кірунках.

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

Выканайце праверкі ў такім парадку

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

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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