OpenVPN-ға қосылдыңыз, бірақ ештеңе жүктелмейді: клиенттен сыртқа қарай жүріс

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

Клиент терезесінде Connected жазылған, туннель мекенжайы бар, ал браузер әлі айналып тұр. Бұл үйлесім қалыпты, себебі сәтті қол алысу туннельдің салынғанын ғана дәлелдейді; ол сервер пакеттеріңізді жіберіп бере ме, олардың көзін қайта жаза ма немесе DNS сұрауларыңызға жауап бере ме — бұл туралы ештеңе айтпайды. Көпшіліктің қателігі — алдымен сервер конфигурациясын ашу. Оның орнына клиенттен сыртқа қарай жұмыс істеңіз, өйткені төмендегі әр қадам келесіні тексерудің қажеті бар-жоғын айтады.

Клиенттен бастап сыртқа қарай жүріңіз

Осы ретпен үш сынақ жасаңыз және біріншісі қай жерде сәтсіз болатынын жазып алыңыз. Сервердің туннель мекенжайына ping жасаңыз, бұл туннельдің өзі трафикті тасымалдайтынын дәлелдейді. Ашық мекенжайға нөмірі бойынша ping жасаңыз, бұл атауды шешуді қоспай-ақ жіберуді және түрлендіруді дәлелдейді. Содан кейін хост атауын шешуге тырысыңыз, бұл DNS-ті пайдаланатын жалғыз сынақ. Әр нәтиже күдіктен тұтас бір қабатты алып тастайды.

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

Екі түсірілім пакеттердің қайда тоқтайтынын көрсетеді

Клиенттен ашық мекенжайға ping жүріп жатқанда туннель интерфейсінде бір, интернетке шығуы тиіс жоғарғы арнада екінші түсірілім жасаңыз. Уақыт белгілері сәйкес болуы үшін екеуін бір уақытта іске қосыңыз.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

Жоғарғы арнаның атауын оқулықтан емес, маршруттау кестесінен алыңыз. Бұлттық бейнелер мен аты өзгертілген адаптерлер нұсқаулықтағы мысал интерфейспен сирек сәйкеседі, ал дұрыс емес құрылғыда жасалған түсірілім жібермейтін серверге тура ұқсайды:

ip -4 route get 9.9.9.9

Осы шығыстағы dev өрісі — NAT ережесіне кейін қажет болатын атау, сондықтан оны сақтап қойыңыз.

Жіберу — ядродағы ажыратқыш және қамал саясаты

Ядро жалпы жіберуге келісуі керек. Ағымдағы мәнді оқыңыз, содан кейін параметрді тек жұмыс істеп тұрған ядроға жазу орнына тұрақты етіп жасаңыз:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Жіберу — жартысы ғана. UFW қолданатын хостта жіберу саясаты /etc/default/ufw ішінде орнатылады және қайта жүктеу күшіне енбес бұрын ACCEPT болуы керек. Жіберу жолындағы әдепкі тастау қол алысуды толық сау қалдырады, бірақ туннельден шығуға тырысқан әрбір пакетті үнсіз тастайды, және бұл сіз бастаған симптомның дәл өзі.

nftables-ті тікелей басқаратын хосттар сол сұраққа басқа синтаксисте тап болады. Клиент сынағы жүріп жатқанда жіберу тізбегіндегі есептегіштерді қараңыз, өйткені сұралатын тізбек пен тастайтын тізбек конфигурация файлында бірдей көрінеді.

NAT ережесінде нақты шығу интерфейсін атаңыз

Көзді түрлендіру хостты шынымен тастайтын интерфейске, сервер беретін пулмен бірге тиесілі. Бұл ереженің екі жартысы да шындықты сипаттауы керек, және екеуі де міндетті.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Классикалық сәтсіздік — нұсқаулықтан көшірілген, адаптері басқаша аталатын машинада -o eth0 дейтін ереже. Ереже ескертусіз орнатылады, ештеңемен сәйкеспейді, ал клиентте интернет жоқ. Пул — сол қатенің екінші жартысы: егер сервер 10.44.0.0/24 берсе, ал ереже 10.8.0.0/24 қамтыса, ештеңе ешқашан сәйкеспейді.

Ереже мәтініне сенудің орнына есептегіштерді қараңыз. Тізім әр ереже бойынша пакеттерді хабарлайды, ал ешқашан сәйкеспейтін ереже қаншалықты дұрыс көрінсе де нөлде қалады. Сол саннан қорытынды жасамас бұрын оған бір минут нақты клиент трафигін беріңіз:

iptables -t nat -L POSTROUTING -v -n

Нақты клиент сынағынан кейін нөлдік пакет саны сәйкестіктің қате екенін білдіреді, туннельдің бұзылғанын емес. Сәйкесе бастағанда ережелер жиынтығын сақтаңыз, ол қайта жүктеуге шыдасын; тек shell тарихында өмір сүретін түзету бірінші қайта жүктеуде жоғалады.

Егер сервер бұлттық NAT данасы болса да, платформаның да сөзі бар. Мекенжайларды түрлендіретін дана әдетте провайдер сол параметрді ұсынатын жерде көз бен межелікті тексеруді өшіруді талап етеді, ал VPN портының өзі сырттан қолжетімді болуы керек.

DNS — біріншісінің артындағы екінші сәтсіздік

Мекенжай бойынша ping жұмыс істеп, атаулар сәтсіз болса, бұл шешуші мәселесі, және оның өз себебі бар. Жергілікті шешушісін сақтайтын клиент бұл сұрауларды толық туннельге жіберіп, ешқашан келмейтін жауапты күтеді, өйткені жергілікті шешуші енді маршруттың дұрыс емес жағында.

Клиент қайдан сұрауды білуі үшін серверден шешуші жіберіңіз. Екі жазба біріншісі қолжетімсіз болса, клиентке балама береді, және екеуі де туннель шынымен рұқсат ететін шешушілер болуы керек.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows клиенттері кейін бәрібір жергілікті шешушіге оралуы мүмкін, және block-outside-dns дәл осының алдын алу үшін бар, бірақ оның құны — тек жергілікті желі шеше алатын атаулардан айырылу. systemd-resolved қолданатын Linux клиенттері скрипт орнатпаса, жіберілген шешушіні жиі елемейді, сондықтан жіберу еленбеді деп қорытынды жасамас бұрын туннель құрылғысы үшін resolvectl status тексеріңіз.

Жүрісті пайдаланушы сезінетіндей аяқтаңыз. Клиенттен нақты бетті жүктеңіз, оның қай мекенжайдан шығатынын растаңыз, серверді қайта жүктеңіз, қайта қосылыңыз және үш сынақты қайталаңыз. Тек сол екінші айналым сақталған ережелердің, қамал саясатының және жіберілген шешушінің бірге аман қалғанын дәлелдейді.

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