Тунелот работи, интернет нема: каде запира проследувањето

Клиентот се поврзува, тунелот носи пинг до портата, а ништо зад неа не одговара. Таа состојба е нормална за порта што отсекогаш требало да обезбеди само пристап до заштитени мрежи, а е дефект за онаа што се рекламира како излез од целосен тунел. Пред да менувате правила, потврдете која услуга е ветена. Потоа следете едно јавно барање низ четирите места каде што може да застане. Едно барање и едно снимање на пакети решаваат повеќе од страница со претпоставки.

Потврдете дали излезот на интернет некогаш бил дизајн

Профилот на поделен тунел насочува само заштитените подмрежи во 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

Преводот на изворот е вообичаениот дел што недостасува. Со него портата го препишува изворот на клиентот на својата јавна адреса и го следи текот; без него одговорот нема каде да оди. Cloud платформите додаваат втора граница, каде табелата со рути или безбедносната група на инстанцата можат да го отфрлат сообраќајот што заштитниот ѕид на гостинот го дозволува. Таа граница е лесно да се пропушти зашто системот на гостинот изгледа правилно конфигуриран однатре.

Филтрирањето на обратниот пат во асиметрична поставеност исто така може да отфрли валидни пакети. Прочитајте го бројачот на тоа правило наместо да претпоставите дека е во ред, зашто строга поставка на јавното интерфејс одбива сообраќај што пристигнува по друг пат од оној што го предвидува табелата со рути.

Патот на одговорот и резолверот се два различни одговори

Внимавајте и на одговорот, не само на барањето. Ако барањето излезе преведено и одговорот се врати во преведениот тек, проследувањето работи дури и кога апликацијата уште не успева, а следната истрага им припаѓа на апликацијата или на DNS.

Страница што враќа HTTP грешка е доказ дека проследувањето на интернет работи. Име што не се разрешува додека пристапот по адреса работи е проблем на резолверот, а не на NAT.

По тесна исправка, повторно тестирајте го клиентот и секој намерно ограничен приватен ресурс. Давањето пристап до интернет не смее тивко да го прошири пристапот до секоја мрежа поврзана со портата.