VPN на роўтары працуе, але кліенты LAN без інтэрнэту

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

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

Чытайце збой з хоста LAN

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

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

Лакальны трафік і перасылаемы трафік розныя

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

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

Зваротны шлях таксама павінен існаваць

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

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

DNS кліента адносіцца да таго ж агляду. Рэзалвер роўтара можа адказваць, а кліент, накіраваны на іншы сервер, не атрымлівае нічога.

Праверце адзін дазволены і адзін забаронены паток

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

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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

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