Трафик шынымен VPN арқылы өте ме? Оны қалай тексеруге болады

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

Пакет жүретін маршруттан бастаңыз

Маршруттау кестесі — шешімнің өзі, сондықтан бәрін оқып болжаудың орнына одан бір мақсат туралы сұраңыз. Linux-та ip route get ядро таңдаған интерфейс пен бастапқы мекенжайды атайды:

ip route get 203.0.113.10
ip route get 10.20.5.7

Windows-та Find-NetRoute -RemoteIPAddress 203.0.113.10 route print -4-тен пайдалырақ, себебі бірдей: ол жеңген маршрутты хабарлайды, барлық маршрутты емес. Дегенмен кестені оның 0.0.0.0 жолы үшін бір рет оқыңыз. Онда /1 жұбы болса, толық туннель клиенті әдепкі маршрутты қайта жазған: OpenVPN-нің redirect-gateway def1 параметрі туннель арқылы 0.0.0.0/1 және 128.0.0.0/1 орнатады, бұл физикалық әдепкі маршрутты жоймай, ең ұзын префикс сәйкестігі бойынша бар 0.0.0.0/0-ды жеңеді. Сондықтан екі әдепкі маршрут қатар өмір сүре алады, ал бәрі бәрібір туннельге кіреді.

Екі бөлшек кестені өтірікшіге айналдырады. Біріншіден, әдепкі маршруттар санына емес, сәйкес келген префикске қараңыз, өйткені жеңімпазды интерфейс метрикасы немесе /1 жұбы анықтайды. Екіншіден, бұрыннан бар қосылым өзі орнаған жолды сақтайды; туннель көтерілген соң ашық сессия қалпына келтірілгенге дейін ескі маршрутты пайдалана алады, сондықтан қайта қосылу маршруттау мәселесін шешкендей көрінеді. Жұмыс істеп тұрған клиент — ps ax | grep openvpn — тек процестің басталғанын дәлелдейді.

Бір ішкі және бір жария атауды бақылаңыз

Маршрутты іздеу ниетті көрсетеді; жол жеткізуді көрсетеді. Қосылған күйде міндетті түрде ішкі болатын атауды және болмауы тиіс атауды бақылап, бірінші секірісті салыстырыңыз:

traceroute intranet.corp.example
traceroute 1.1.1.1

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

Сүзілген ICMP бұл тексеруді өтірікшіге айналдырады: екі ізде де жұлдызшалар өлі туннельге ұқсайды және әдетте ол брандмауэр. Мүмкін жерде TCP портын тексеріңіз — Linux-та traceroute -T -p 443 — және із қай шешуші жауап бергенін айтпайтынын есте сақтаңыз: атау жергілікті шешіліп, бәрібір туннель арқылы қолжетімді болуы мүмкін.

Туннельде емес, физикалық адаптерде түсіріңіз

Физикалық байланыс — желінің шын мәнінде нені көретінін көрсететін жалғыз орын. Туннель көтерілген кезде кеңсеге сессия VPN серверіне арналған шифрланған жүктеме ретінде көрінуі керек, 10.20.5.7-ке қосылым ретінде емес:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Бірінші сүзгі жергілікті шығатын атау шешімін ұстайды, бұл ең көп тараған және ең тыныш ағу — бет бәрібір жүктеледі, шешуші сұранысты ғана көрді. Екіншісі туннельдің ішінде ғана болуы тиіс ішкі мекенжайға қарай қарапайым трафикті ұстайды. Windows-та pktmon дәл сол жұмысты драйверсіз жасайды: pktmon filter add -p 53, содан кейін pktmon start --capture --pkt-size 128, содан кейін pktmon stop және pktmon format pktmon.etl -o capture.txt. Бұл жалаушалар Windows құрастырылымдары арасында аздап ерекшеленеді, сондықтан синтаксиске сенбес бұрын pktmon filter add /? тексеріңіз.

Ағуды табу үшін физикалық интерфейсті түсіріңіз; туннельде түсіру сіз онда деп ойлайтын пакеттерді қамтиды, ал серверде ол көзі шлюз болып табылатын оқылмайтын сыртқы пакеттерді қамтиды. Кез келген интерфейстегі байт санағыштары пакеттерді сипаттайды, бағдарламаларды емес; трафикті процеске телу үшін сокеттерді процестермен байланыстыратын монитор қажет.

Сыртқы қызметтен сұраңыз, содан кейін әр қолданба үшін қайта сұраңыз

Шығуды дәлелдейтін жалғыз тексеру — сырттан келген жауап: көрген бастапқы мекенжайды қайтаратын қызмет. Оны интерфейсті таңдай алатын қабықтан іске қосыңыз және екі рет іске қосыңыз:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Әртүрлі жауаптар сізге екі жолдың дәлелін және нақты қолданбаны тексеру тәсілін береді: оны байланыстырыңыз немесе бір маршрутты желілік атау кеңістігінде іске қосыңыз да, алыс жақ қай мекенжайды тіркейтінін көріңіз. Бірдей жауаптар — қызықты ақау: не байланыстыру әсер етпеді, не хост пен алыс жақ арасындағы бірдеңе жетпей тұрып бастапқы мекенжайды қайта жазады. Windows-та curl --interface адаптердің атауын емес, мекенжайын қалайды.

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

Теңдесті растау үшін сервер көрінісін пайдаланыңыз

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

Мұнда екі тұзақ бар. Маскаланған туннель әр ағынды шлюзден келгендей көрсетеді, сондықтан журналдар мен клиент бойынша есеп бір мекенжайға жиналады. Ал клиент жергілікті хост ретінде қаралады, сондықтан біреудің VPN арқылы файл көшіруі туралы сұраққа сервердегі файл бөлісу трафигі немесе сервердегі хост аудиті жауап береді — туннельді бақылау соңғы нүктелер мен көлемді береді, файл атауларын емес.

Дизайн шешімін ағудан ажыратыңыз

Туннельден тыс барлық нәрсе ағу емес. Байланыс-жергілікті және тарату трафигі дизайн бойынша жергілікті қалады, multicast арқылы табылған принтер LAN-да хабарландыруды жалғастырады, ал DHCP жергілікті шығуы керек. Белгілі бір интерфейске байланған қолданба маршруттау кестесін әдейі айналып өтеді, мұны тек брандмауэр ережесі, атау кеңістігі немесе саясат маршруты өзгертеді.

IPv6 тізімде өз жолына лайық. Тек IPv4 таситын туннель қос стекті хостқа екінші пайдалануға болатын жол қалдырады, ал қос стекті мақсат соны қалайды — DNS-ті қоса, егер шешуші IPv6 арқылы қолжетімді болса. IPv4 нәтижесін толық деп санамас бұрын адаптерде IPv6-ны өшіріңіз немесе туннель оны таситынын растаңыз.

Тексерулер сәйкеспесе, сәйкессіздік әдетте ақауды атайды:

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