Кліенты OpenVPN праз мост без інтэрнэту? Праверце правіла NAT

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

Доказ — гэта лічыльнік, а не радок у табліцы

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

iptables -t nat -L POSTROUTING -v -n

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

Знайдзіце імя, якое ядро сапраўды запісвае

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

ip -brief link

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

Перапішыце правіла пад прыладу тунеля

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

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

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

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

Чаму фізічная карта ніколі не супадае

Мост — гэта праграмны камутатар, сабраны з прылады tap і аднаго фізічнага інтэрфейса. Кадр кліента ўваходзіць у гэты камутатар і выходзіць да фізічнай сеткі як член моста, а не як пакет на карце. Таму ядро прыпісвае пакет мосту і яго порту, і менавіта таму карта, пра якую вы думалі, ніколі не з’яўляецца ў супадзенні. З фізічным інтэрфейсам нічога не зламана; ён проста не тая прылада, якой ядро прыпісвае гэты пакет.

Наступная праблема, з якой сутыкаюцца людзі, паходзіць з той жа структуры: фільтраванне кадраў на мосце — асобны сродак ад фільтравання IP. Калі патрабуецца абмежаванне на ўзроўні кадраў, яно належыць да фільтравання моста, а не да правіла табліцы IP.

Давядзіце гэта ад пачатку да канца, потым зрабіце сталым

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

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

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