Туннель көтерілді, интернет жоқ: қайта бағыттау қайда тоқтайды

Аутентификация мен жұмыс істеп тұрған туннель интернетке шығуды білдірмейді. Бір сұранысты дереккөздің мекенжайлануы, қайта бағыттау және жауап жолы арқылы бақылаңыз.

Клиент қосылады, туннель шлюзге пінг жеткізеді, ал оның арғы жағында ештеңе жауап бермейді. Бұл күй тек қорғалған желілерге қолжеткізу үшін ғана жасалған шлюз үшін қалыпты, ал толық туннель шығысы ретінде жарнамаланған шлюз үшін ақау. Ережелерді өзгертудің алдында қандай қызмет уәде етілгенін растаңыз. Содан кейін бір жария сұранысты оның тоқтай алатын төрт жерінен бақылаңыз. Бір сұраныс пен бір пакет жазбасы бір бет болжамнан да көп нәрсені шешеді.

Интернетке шығу әуел бастан жоба болды ма, соны растаңыз

Бөлінген туннель профилі 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 мәселесі емес.

Нақты түзетуден кейін клиентті және әдейі шектелген кез келген жеке ресурсты қайта тексеріңіз. Интернетке қолжеткізу беру шлюзге қосылған әрбір желіге қолжеткізуді үнсіз кеңейтпеуі керек.

Қатысты мақалалар