Абмяжуйце правіла SNAT для OpenVPN, пакуль яно не зламала nginx

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

Пераканайцеся, што кантэйнер можа стварыць прыладу tun

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

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

Вызначце, што робіць MASQUERADE на гэтым інтэрфейсе

На звычайнай віртуальнай машыне звычайнае правіла выхаду — гэта POSTROUTING MASQUERADE з галоўнага інтэрфейса. У кантэйнеры OpenVZ бачная прылада часта venet0, гэта значыць віртуальны інтэрфейс, якім кіруе хост, а не маршрутызаваная сеткавая карта, і MASQUERADE там не заўсёды паводзіць сябе так, як мяркуюць падручнікі.

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

Абмяжуйце правіла адным пулам і адным інтэрфейсам

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

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

Рашэнне — звузіць супадзенне да пула тунеля і выхаднога інтэрфейса, а потым дадаць адно правіла на пул замест пашырэння аднаго правіла на некалькі.

Зрабіце правілы пастаяннымі і высветліце, хто яшчэ імі валодае

Правілы, дададзеныя ўручную, знікаюць пры перазагрузцы, таму захавайце іх з iptables-save або кіруйце імі праз netfilter-persistent там, дзе ён усталяваны. Пераканайцеся, што аднаўленне выконваецца да запуску OpenVPN. Потым аднойчы наўмысна перазагрузіцеся, замест таго каб выявіць прабел падчас інцыдэнту.

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

Праверце лічыльнікамі і адным захаваным патокам

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

На серверы чытайце лічыльнікі пакетаў на правілах NAT і FORWARD з iptables -t nat -L -v -n і назірайце за адным патокам у запісе. Калі адрас кліента з’яўляецца ў запісе і адказу не ідзе, прабел на адваротным шляху або ў фільтрацыі правайдэра, а не ў профілі кліента. Параўнайце захопленую крыніцу з адрасам, на які транслюе правіла, бо разыходжанне азначае, што першым супала іншае правіла. Адзін назіраны паток вырашае больш, чым старонка чытання канфігурацыі.

Трымайце пул, трансляваны адрас і імя інтэрфейса разам у запісе змен. Правіла, правільнае для аднаго пула, няправільна транслюе наступны.