Trafik haqiqatan VPN orqali o'tyaptimi? Buni qanday tekshirish kerak

Tizim patnisidagi belgidan ikkita nosozlik bir xil ko'rinadi: tunnelga kiradigan trafik va uni jimgina chetlab o'tadigan trafik. Mijoz ikkala holatda ham Connected ko'rsatadi, chunki Connected faqat tunnel interfeysi mavjudligini va mijoz kerakli marshrutlarni o'rnatganini bildiradi. Bitta dasturning bitta paketi o'sha marshrutlardan foydalanganmi — bu alohida savol bo'lib, unga stekning boshqa joyida javob beriladi. To'rt o'lchov buning ko'p qismini hal qiladi — marshrut qidiruvi, birinchi sakrash, jismoniy adapterda ushlash va tashqaridan kuzatish — serverning o'z sessiya ko'rinishi esa qolganini qoplaydi.

Paket bosib o'tadigan marshrutdan boshlang

Marshrutlash jadvali qarorning o'zi, shuning uchun hammasini o'qib taxmin qilish o'rniga undan bitta manzil haqida so'rang. Linuxda ip route get yadro tanlagan interfeys va manba manzilini nomlaydi:

ip route get 203.0.113.10
ip route get 10.20.5.7

Windowsda Find-NetRoute -RemoteIPAddress 203.0.113.10 route print -4 dan foydaliroq, sababi bir xil: g'olib bo'lgan marshrutni xabar qiladi, mavjud barcha marshrutlarni emas. Baribir jadvalni uning 0.0.0.0 qatori uchun bir marta o'qing. U yerda /1 juftligi to'liq tunnel mijozi standart marshrutni qayta yozganini bildiradi: OpenVPN ning redirect-gateway def1 opsiyasi tunnel orqali 0.0.0.0/1 va 128.0.0.0/1 ni o'rnatadi, bu jismoniy standartni o'chirmasdan eng uzun prefiks mosligida mavjud 0.0.0.0/0 ni yengadi. Shuning uchun ikkita standart marshrut birga bo'lishi mumkin, ammo hammasi baribir tunnelga kiradi.

Ikkita tafsilot jadvalni yolg'onchi qiladi. Birinchidan, standart marshrutlar soniga emas, mos kelgan prefiksga qarang, chunki g'olibni interfeys metrikasi yoki /1 juftligi belgilaydi. Ikkinchidan, allaqachon mavjud ulanish o'rnatilgan yo'lni saqlaydi; tunnel ko'tarilgandan so'ng ochiq sessiya qayta ishga tushirilgunga qadar eski marshrutdan foydalanishi mumkin, shuning uchun qayta ulanish marshrutlash muammosini tuzatganday ko'rinadi. Ishlab turgan mijoz — ps ax | grep openvpn — faqat jarayon boshlanganini isbotlaydi.

Bitta ichki va bitta ommaviy nomni kuzatib boring

Marshrut qidiruvi niyatni ko'rsatadi; yo'l yetkazishni ko'rsatadi. Ulangan holda ichki bo'lishi shart bo'lgan nom va bo'lmasligi kerak nomni kuzatib, birinchi sakrashni solishtiring:

traceroute intranet.corp.example
traceroute 1.1.1.1

Ikkalasi uchun bir xil birinchi sakrash ichki nom hech qachon tunnelga kirmaganini va nosozlik uning ustida ekanini bildiradi, odatda ommaviy manzilga yechiladigan nom yoki hech qachon o'rnatilmagan marshrut. Ichki trafik 10.8.0.1 orqali chiqib, ommaviy trafik 192.168.1.1 orqali chiqsa, bo'lingan tunnel aynan o'zi uchun sozlangan ishni qiladi. VPN shlyuziga yetib, keyin faqat vaqt tugashini qaytaradigan iz odatda qaytish yo'li yoki server xavfsizlik devori muammosi, yo'qolgan yo'naltirish marshruti emas.

Filtrlangan ICMP bu tekshiruvni yolg'onchi qiladi: ikkala izda yulduzchalar o'lik tunnelga o'xshaydi va odatda bu xavfsizlik devori. Imkon bo'lgan joyda TCP portni sinab ko'ring — Linuxda traceroute -T -p 443 — va iz qaysi hal qiluvchi javob berganini aytmasligini yodda tuting: nom mahalliy yechilib, baribir tunnel orqali yetib borishi mumkin.

Tunnelda emas, jismoniy adapterda ushlang

Jismoniy bog'lanish tarmoq aslida nimani ko'rishini ko'rsatadigan yagona joy. Tunnel ko'tarilganda ofisga sessiya VPN serveriga yo'naltirilgan shifrlangan yuk sifatida ko'rinishi kerak, 10.20.5.7 ga ulanish sifatida emas:

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

Birinchi filtr mahalliy chiqadigan nom yechimini ushlaydi, bu eng keng tarqalgan va eng jim sizib chiqish — sahifa baribir yuklanadi, hal qiluvchi faqat so'rovni ko'rdi. Ikkinchisi faqat tunnel ichida bo'lishi kerak ichki manzilga oddiy trafikni ushlaydi. Windowsda pktmon drayversiz xuddi shu ishni qiladi: pktmon filter add -p 53, keyin pktmon start --capture --pkt-size 128, keyin pktmon stop va pktmon format pktmon.etl -o capture.txt. Bu bayroqlar Windows versiyalari orasida biroz farq qiladi, shuning uchun sintaksisga ishonishdan oldin pktmon filter add /? ni tekshiring.

Sizib chiqishlarni topish uchun jismoniy interfeysni ushlang; tunnelda ushlash siz allaqachon bor deb hisoblagan paketlarni o'z ichiga oladi, serverda esa manbasi shlyuz bo'lgan o'qilmas tashqi paketlarni o'z ichiga oladi. Har qanday interfeysdagi bayt hisoblagichlari paketlarni tavsiflaydi, dasturlarni emas; trafikni jarayonga bog'lash uchun soketlarni jarayonlar bilan bog'laydigan monitor kerak.

Tashqi xizmatdan so'rang, keyin har bir dastur uchun yana so'rang

Chiqishni isbotlaydigan yagona tekshiruv tashqaridan kelgan javob: o'zi ko'rgan manba manzilini qaytaradigan xizmat. Uni interfeys tanlash mumkin bo'lgan qobiqdan ishga tushiring va ikki marta ishga tushiring:

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

Turli javoblar ikki yo'lning isbotini va aniq dasturni sinash usulini beradi: uni bog'lang yoki bitta marshrutli tarmoq nom maydonida ishga tushiring va uzoq tomon qaysi manzilni qayd etishini ko'ring. Bir xil javoblar qiziqarli nosozlik: yo bog'lash ta'sir qilmadi, yo host va uzoq tomon orasida nimadir yetib borishdan oldin manba manzilini qayta yozadi. Windowsda curl --interface adapterni nomini emas, manzilini talab qiladi.

VPN manzilini xabar qiladigan brauzer brauzerni isbotlaydi. Pochta mijozi, paket menejeri, zaxira agenti yoki ikkinchi brauzer profili har biri boshqa yo'l tutishi mumkin, ayniqsa proksi sozlamasi yoki bo'lingan tunnel marshruti ulardan birini qoplaganda. Manzilning o'zgarishi o'z-o'zidan sizib chiqish isboti emas: yuk balanslovchi ko'rgan chiqishga qarab boshqacha javob berishi mumkin, shuning uchun sahifani emas, qayd etilgan manba manzilini solishtiring.

Tengdoshni tasdiqlash uchun server ko'rinishidan foydalaning

Server boshqa savolga javob beradi: tengdosh ulanganmi, qancha o'tkazgan va sessiya qayta boshlanganmi. Serverda tengdosh faol bo'lib, mijoz hisoblagichlari deyarli qimirlamasa, mijoz jadvali nima deganidan qat'i nazar dastur trafigi tunnelga kirmayotganini bildiradi. Hech narsa ishlamayotganini aytgan foydalanuvchi uchun ko'p ma'lumot o'tkazayotgan tengdosh esa boshqa tekshiruv.

Bu yerda ikkita tuzoq bor. Niqoblangan tunnel har bir oqimni shlyuzdan kelganday ko'rsatadi, shuning uchun jurnallar va har bir mijoz bo'yicha hisob bitta manzilga yig'iladi. Mijoz esa mahalliy host sifatida qaraladi, shuning uchun kimdir VPN orqali fayllarni nusxalayaptimi degan savolga serverdagi fayl almashish trafigi yoki serverdagi host auditi javob beradi — tunnelni kuzatish tugunlar va hajmni beradi, fayl nomlarini emas.

Dizayn qarorini sizib chiqishdan ajrating

Tunneldan tashqaridagi hamma narsa sizib chiqish emas. Bog'lanish-mahalliy va tarqatish trafigi dizayn bo'yicha mahalliy qoladi, multicast orqali topilgan printer LANda e'lon qilishni davom ettiradi, DHCP esa mahalliy chiqishi kerak. Muayyan interfeysga bog'langan dastur marshrutlash jadvalini ataylab chetlab o'tadi, buni faqat xavfsizlik devori qoidasi, nom maydoni yoki siyosat marshruti o'zgartiradi.

IPv6 tekshiruv ro'yxatida o'z satriga loyiq. Faqat IPv4 tashiydigan tunnel ikki stekli hostga ikkinchi ishlatsa bo'ladigan yo'lni qoldiradi va ikki stekli manzil o'shani afzal ko'radi — DNS ham, agar hal qiluvchi IPv6 orqali yetib borilsa. IPv4 natijasini to'liq deb hisoblashdan oldin adapterda IPv6 ni o'chiring yoki tunnel uni tashishini tasdiqlang.

Tekshiruvlar mos kelmasa, nomuvofiqlik odatda nosozlikni nomlaydi:

Ishlaydigan tartib: marshrutlash jadvalini ulanishdan oldin va keyin saqlang, bitta ichki va bitta ommaviy nomni kuzatib boring, jismoniy adapterda DNS ushlang, aniq dastur uchun qobiqdan chiqish manzilini qaytaring, keyin hajm uchun serverni o'qing. Birinchi to'rttasi mos kelsa, tunnel siz o'ylagan narsani tashiyapti va qolgan muammo uning ustida. Ikkitasi mos kelmasa, mos kelmagan juftlik nosozlik, belgi emas.