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

Дзве ролі незалежныя, як і два сямействы адрасоў.

Адказ на ўласны адрас нічога не даказвае

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

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

Тое ж самае тычыцца міжсеткавага экрана перад рашэннем аб перадачы, у якога ёсць уласная палітыка наконт таго, што можна перадаваць.

Правярайце кожнае сямейства адрасоў асобна

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

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

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

Перадача — адно з чатырох патрабаванняў

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

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

Тэстуйце з кліента, а не са шлюза

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

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

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

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