Тунэль узняты, інтэрнэту няма: дзе спыняецца перасылка

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

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

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

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

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

Прасачыце адзін публічны запыт

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

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

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

Праверце перасылку, маршрут і трансляцыю

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

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

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

Зваротны шлях і распазнавальнік імёнаў — два розныя адказы

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

Сайт, што вяртае памылку HTTP, даказвае, што перасылка ў інтэрнэт працуе. Імя, якое не распазнаецца, тады як доступ па адрасе працуе, — гэта праблема распазнавальніка, а не NAT.

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

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