Тунелът работи, интернет няма: къде спира препращането

Клиентът се свързва, тунелът пренася ping до шлюза и нищо отвъд него не отговаря. Това състояние е нормално за шлюз, който винаги е бил предназначен само да дава достъп до защитени мрежи, и е повреда за такъв, който се рекламира като изход на пълен тунел. Преди да променяте правила, потвърдете каква услуга е била обещана. След това проследете една публична заявка през четирите места, където може да спре. Една заявка и едно заснемане на пакети решават повече от страница с предположения.

Потвърдете дали изходът към интернет някога е бил дизайнът

Профил на разделен тунел насочва само защитените подмрежи към VPN, така че публичното сърфиране продължава по локалната връзка и никога не докосва шлюза. Профил на пълен тунел инсталира маршрут по подразбиране в тунела, което прави шлюза отговорен за целия път. И двете са законни дизайни, а смесването им създава доклад за повреда там, където няма такава. Прочетете обявените от клиента маршрути, преди да тествате каквото и да е друго, защото таблицата с маршрути отговаря на въпроса, който тикетът обикновено поставя грешно.

Това, което клиентът инсталира, не винаги е това, което профилът предвижда. Изпратен маршрут може да бъде надписан от локален маршрут с по-ниска метрика, а клиент, който запазва LAN маршрута си, докато добавя маршрут по подразбиране, се държи като разделен тунел за тази подмрежа.

Проследете една публична заявка

Изберете една дестинация и я проследете от клиента навън. На клиента проверете дали пакетът наистина избира тунела и кой локален адрес използва като източник. След това проверете шлюза: пристига ли пакетът и напуска ли публичния интерфейс. Всеки от тези отговори премахва цяла категория причини.

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.

След тясна корекция тествайте отново клиента и всеки умишлено ограничен частен ресурс. Предоставянето на достъп до интернет не бива тихо да разширява достъпа до всяка мрежа, свързана с шлюза.