Сіз VPN сервері ноутбугіңіздің мекенжайын пакеттен оқып, журналға жазады деп елестетесіз. Ол оқитын нәрсе — соңғы NAT секірісі сыртқы тақырыпқа салған мекенжай, ал хотспот ретінде пайдаланылатын телефонда бұл көбіне жүздеген басқа абонентпен ортақ мекенжай болады. Өз машинаңыздың 192.168.x.x мекенжайы сол тақырыпта интернеттен ешқашан өтпейді, ал туннель мекенжайын сервер қосылым әлдеқашан орнағаннан кейін береді. Сондықтан сервер журналы мен ноутбуктегі ip addr сәйкес келмесе, екеуі де қате емес; олар бір сессияның әртүрлі қабаттарын сипаттайды.

Үш мекенжай, ал журналда тек біреуі

Шатасу үш мекенжайды біріне біріктіруден туындайды. Әрқайсысының иесі басқа, ол басқа тақырыпта тұрады және серверге басқа жолмен жетеді.

AddressWho assigns itWhere it sitsVisible to the VPN server
Device address, e.g. 192.168.1.24Your router via DHCPOuter header, before translationNo, rewritten in place
Translated address and portRouter, ISP CGNAT, or bothOuter header, after translationYes, this is the tuple it logs
Tunnel address, e.g. 10.8.0.6The VPN server itselfInner header, after decapsulationYes, but it chose it

Қосылу сәтінде тек ортаңғы жол белгісіз. Сервер оны демонға қарай өзінің серіктестер кестесіне, күй файлына немесе ағын журналына жазады: WireGuard оны соңғы нүкте деп атайды, OpenVPN күй файлы оны Real Address деп белгілейді, ал strongSwan оны IKE_SA-ның қашықтағы хосты ретінде хабарлайды. Бұл мән басқа көзден пакет келген сайын жаңарады, сондықтан ешкім ештеңені қайта қоспай-ақ өзгереді.

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

Туннель тұрған кезде журналдағы кортеж неге өзгереді

Мекенжайларды түрлендіру — таймері бар кесте, тұрақты байланыс емес. Үй маршрутизаторы соңғы пакеттен кейін UDP бейнелеуін біраз уақыт сақтайды, оператор қақпасы порттарды өз кестесі бойынша қайта пайдаланады, ал Wi-Fi-дан LTE-ге ауысқан телефон мүлде басқа көзбен оралады. Linux conntrack-тың әдепкі мәндері осында пайдалы өлшем: nf_conntrack_udp_timeout 30 секунд, ал ағынды нұсқасы 120, сондықтан тыныш туннель пайдаланушы байқағанға дейін әлдеқайда бұрын бейнелеуін жоғалтуы мүмкін.

Туннель тірі қалады, өйткені протокол мекенжайды емес, серіктесті аутентификациялайды. WireGuard қол алысқаннан кейін күйсіз, сондықтан кез келген аутентификацияланған пакет сақталған соңғы нүктені жаңартады және қайта байлау келесі пакетте қалпына келеді; persistent-keepalive = 25 дәл сондықтан бар — бос тұрғанда бейнелеуді жылы ұстау үшін. OpenVPN-ның --float параметрі де сол жұмысты атқарады және аутентификацияланған клиентке жаңа мекенжай мен порттан жалғастыруға мүмкіндік береді. float әдепкі бойынша өшірулі 2.4 және 2.5 жинақтарында қайта байлау сессияны қалпына келтіреді және клиент қайта қосылады.

IPsec ол жерге көбірек қозғалмалы бөліктермен жетеді. IKEv2 NAT анықтау жүктемелеріндегі көз бен межелі хэштерді салыстыру арқылы түрлендіруді байқайды, UDP 4500 инкапсуляциясына көшеді және keepalive-терді жаңа кортежге дейін қадағалайды. Keepalive-тер бұғатталғанда SA қағазда тұрған күйінде қалады, ал бір бағыттағы трафик үнсіз тоқтайды.

Сервер нені тели алады, нені алмайды

Жоюға тұрарлық миф — түрлендіру сізді оператордан жасырады деген пікір. Ол белгіні өзгертеді, бақылауды емес. Оператор NAT-ының артындағы қақпа 100.64.0.0/10 кеңістігін немесе көптеген абонент ортақ пайдаланатын бір жария мекенжайды көреді және ағынды сертификат субъектісіне, WireGuard жария кілтіне, берілген туннель мекенжайына, байт санағыштарына және уақыт терезесіне байланыстыра алады. Олардың ешқайсысына сіздің LAN мекенжайыңыз қажет емес.

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

Болжаудың орнына екі ұшты салыстырыңыз

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

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Содан кейін маршрутизатордағы немесе CGNAT қақпасындағы түрлендіру жазбасын және серверге ақырында не жететінін оқыңыз:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Сәйкессіздіктердің көбін үш үлгі түсіндіреді. Сервердегі көз порты жергілікті порттан өзгеше, ал межелі сәйкес келеді: қарапайым порт түрлендіруі. Сервердегі көз мекенжайы сіздікі емес ISP блогына жатады: кемінде бір қосымша NAT қабаты. Пакеттер бос тұрғаннан кейін тоқтап, жаңа портпен жалғасады: бейнелеу мерзімі бітті, маршруттау ақауы емес. Уақыт белгілері бір-екі секундтан көп алшақ болса, сіз екі түрлі әрекетті салыстырып жатырсыз.

Айырмашылық қай жерде бәрін бұзады

Сервер ақауына ұқсайтын үзілістер әдетте осы жерден басталады. Үй мекенжайыңызға бекітілген рұқсат ережесі ISP жалдауы өзгергеннен кейін істен шығады. Түрлендірілген мекенжайға сәйкес келетін fail2ban ережесі сол қақпаның артындағы барлық абонентті бірден бұғаттайды. Тұрақты қашықтағы мекенжайы бар сайт-сайт серіктесі мобильді байланыс өзгергеннен кейін кілттерді жаңартуды тоқтатады. Туннель протоколы ретінде еді; сыртқы кортеж туралы болжам олай емес еді.

Дәл осы шатасу сервер жағында да көрінеді. Егер VPN қорабы өзі NAT-тың артында болса, портты бағыттау және жұмыс істейтін бағыттау жолы қажет; strongSwan бағыттау нұсқаулығы IPsec үшін осы жағдайды қамтиды. Тек жеке мекенжайда қолжетімді сервер өз клиенттері ұсынатын түрлендірілген кортежді ешқашан көрмейді, және бұл клиенттердің түрленуінен басқа мәселе.

Осы төрт тексерісті ретімен орындаңыз және бірінші сәтсіз болғанында тоқтаңыз:

  • Екі ұшта бір уақытта түсіріңіз; көз порты, межелі порты және уақыт белгілері сәйкес келетінін растаңыз.
  • Сервердің серіктестер тізімінен күткен мекенжайды емес, қазір ұстап тұрған мекенжайды оқыңыз.
  • Жазба мен оның қалған өмірін conntrack немесе NAT кестесінен тексеріңіз.
  • Клиенттегі туннель интерфейсінің мекенжайы LAN мекенжайына емес, сервер берген мекенжайға сәйкес келетінін растаңыз.

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

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