Рукапацісканне PiVPN працуе, старонкі завісаюць: праверце MASQUERADE

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

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

Пачніце з таго, да чаго кліент мае доступ, а да чаго не

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

Адрас тунеля, які адказвае на ping, пакуль публічныя сайты сканчаюцца па тайм-ауце, — гэта прыкмета праблемы перасылкі або трансляцыі, а не зламанага рукапаціскання. Уласная панэль стану кліента не можа іх адрозніць, бо яна ведае толькі, што кантрольны канал узняты. Праверце на серверы інтэрфейс тунеля з дапамогай ip -br addr show tun0 і пераканайцеся, што прызначаны кліенту адрас трапляе ў пул, які вы наладзілі. Калі пул і адрас кліента не супадаюць, спачатку выпраўце гэта, бо кожнае правіла ніжэй супастаўляецца з пулам.

Далей спытайце сервер, праз які інтэрфейс ён дасягнуў бы публічнага адраса. ip route get 203.0.113.9 друкуе выбраныя прыладу і крыніцу ў першым радку. Запішыце імя гэтай прылады, бо менавіта гэта значэнне павінна быць у правіле NAT.

Прачытайце правіла, якое вырашае, ці выйдуць пакеты

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

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

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

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

Выпраўце захаваны набор правілаў, а не толькі бягучы

Праўка толькі жывой табліцы трымаецца да наступнай перазагрузкі, а гэтага роўна дастаткова, каб пераканаць вас, што праблема вырашана. Правілы, якія вяртаюцца пры загрузцы, жывуць у файле, які перазагружае пакет захавання файрвола. На вобразах Pi на базе Debian гэты файл звычайна /etc/iptables/rules.v4.

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

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Дзве суседнія налады лёгка забыць. sysctl net.ipv4.ip_forward павінна паказваць 1, а вышэйшы маршрутызатар не павінен фільтраваць прыватныя адрасы крыніц сам па сабе.

Дакажыце, што правіла спрацоўвае, затым ізалюйце тое, што яшчэ павольна

Лічыльнікі — адзіны сумленны доказ таго, што правіла супала. Запусціце падрабязны спіс, пачніце загрузку на кліенце і запусціце яго зноў. Слупкі пакетаў і байтаў побач з вашым правілам павінны расці, а правіла, якое застаецца на нулі, усё яшчэ не супадае. Калі лічыльнікі рухаюцца, а старонкі ўсё яшчэ падаюць, параўнайце дыяпазон крыніцы з фактычным пулам з дапамогай grep -n "^server " /etc/openvpn/server.conf. Калі яны рухаюцца і старонкі загружаюцца, але прапускная здольнасць дрэнная, трансляцыя завершана, і рэшткавая праблема ў іншым месцы.

Параўнайце дзве перадачы ад аднаго кліента: адну да хоста ў лакальнай сетцы і адну праз тунель да таго ж хоста. Павольнасць у абодвух выпадках паказвае на вышэйшы канал Pi або Wi-Fi-злучэнне, а не на VPN. Павольнасць толькі праз тунель паказвае на MTU і паўторныя перадачы, якія можна агледзець з дапамогай ip -s link show tun0 перш чым мяняць якія-небудзь налады шыфравання.

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

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