Mijoz oynasida Connected yozilgan, tunnel manzili bor, brauzer esa hali ham aylanmoqda. Bu birikma odatiy, chunki muvaffaqiyatli qo'l berish faqat tunnel qurilganini isbotlaydi; u server paketlaringizni uzatadimi, ularning manbasini qayta yozadimi yoki DNS so'rovlaringizga javob beradimi — buni aytmaydi. Ko'pchilikning xatosi — avval server konfiguratsiyasini ochish. Buning o'rniga mijozdan tashqariga qarab ishlang, chunki quyidagi har bir qadam keyingisini tekshirishga arziydimi-yo'qmi, shuni aytadi.

Mijozdan boshlang va tashqariga yuring

Ushbu tartibda uchta sinov o'tkazing va birinchisi qayerda muvaffaqiyatsiz bo'lishini yozib oling. Serverning tunnel manziliga ping yuboring, bu tunnelning o'zi trafik tashiishini isbotlaydi. Raqam bilan ochiq manzilga ping yuboring, bu nom hal qilishni qo'shmasdan uzatish va tarjimani isbotlaydi. So'ng xost nomini hal qilishga urinib ko'ring, bu DNS ishlatadigan yagona sinov. Har bir natija shubhadan butun bir qatlamni olib tashlaydi.

Brauzer tezroq tuyulgani uchun uchinchi sinovga sakramang. Muvaffaqiyatsiz sahifa yuklanishi uchta qatlamni bir vaqtda qoplaydi, va aynan shu yerdan boshlab odamlar keyin ishlagan tunnelni qaytadan quradi. Muvaffaqiyatsiz sahifa uchtadan qaysi biri buzilganini aytmaydi.

Ikkita tutish paketlar qayerda to'xtashini ko'rsatadi

Mijozdan ochiq manzilga ping ketayotganda tunnel interfeysida bitta, internetga chiqishi kerak bo'lgan yuqori kanalda ikkinchi tutish qiling. Vaqt belgilari mos kelishi uchun ikkalasini bir vaqtda ishga tushiring.

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

Agar so'rovlar tunnelda ko'rinib, yuqori kanalda hech qachon ko'rinmasa, server ularni tunnel va sim o'rtasida tashlab yuborgan, sababi esa uzatish yoki uzatish uchun xavfsizlik devori siyosati, NAT emas. Agar ikkalasida ham ko'rinsa, server o'z qismini qilgan va javob narigiroq yo'qolgan, bu tarjima, yuqoridagi filtr yoki provayder tomonidagi cheklovga ishora qiladi.

Yuqori kanal nomini qo'llanmadan emas, marshrutlash jadvalidan oling. Bulut tasvirlari va nomi o'zgartirilgan adapterlar qo'llanmadagi misol interfeysga kamdan-kam mos keladi, va noto'g'ri qurilmada olingan tutish uzatmayotgan serverga xuddi o'xshaydi:

ip -4 route get 9.9.9.9

O'sha chiqishdagi dev maydoni NAT qoidasiga keyinroq kerak bo'ladigan nom, shuning uchun uni saqlab qo'ying.

Uzatish — yadrodagi kalit va xavfsizlik devori siyosati

Yadro umuman uzatishga rozi bo'lishi kerak. Joriy qiymatni o'qing, so'ng sozlamani faqat ishlab turgan yadroga yozish o'rniga doimiy qiling:

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

Uzatish — faqat yarmi. UFW ishlatadigan xostda uzatish siyosati /etc/default/ufw ichida o'rnatiladi va qayta yuklash kuchga kirishidan oldin u ACCEPT bo'lishi kerak. Uzatish yo'lidagi standart tashlab yuborish qo'l berishni butunlay sog'lom qoldiradi, lekin tunneldan chiqishga urinayotgan har bir paketni jimgina tashlab yuboradi, va bu siz boshlagan alomatning aynan o'zi.

nftables ni bevosita boshqaradigan xostlar xuddi shu savolga boshqa sintaksisda duch keladi. Mijoz sinovi ketayotganda uzatish zanjiridagi hisoblagichlarni kuzating, chunki so'raladigan zanjir va tashlab yuboradigan zanjir konfiguratsiya faylida bir xil ko'rinadi.

NAT qoidasida haqiqiy chiqish interfeysini nomlang

Manba tarjimasi xostni haqiqatda tark etadigan interfeysga tegishli, server tarqatadigan hovuz bilan birga. Bu qoidaning ikkala yarmi ham voqelikni tasvirlashi kerak, va hech biri ixtiyoriy emas.

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

Klassik muvaffaqiyatsizlik — qo'llanmadan ko'chirilgan qoida -o eth0 deb aytadi, lekin o'sha mashinaning adapteri boshqacha nomlanadi. Qoida ogohlantirishsiz o'rnatiladi, hech narsaga mos kelmaydi, va mijoz hali ham internetsiz qoladi. Hovuz ham xuddi shu xatoning ikkinchi yarmi: agar server 10.44.0.0/24 tarqatsa va qoida 10.8.0.0/24 ni qoplasa, hech narsa hech qachon mos kelmaydi.

Qoida matniga ishonish o'rniga hisoblagichlarni kuzating. Ro'yxat har bir qoida bo'yicha paketlarni xabar qiladi, va hech qachon mos kelmaydigan qoida qanchalik to'g'ri ko'rinmasin, nolda qoladi. O'sha raqamdan biror narsa o'qishdan oldin unga bir daqiqa haqiqiy mijoz trafigini bering:

iptables -t nat -L POSTROUTING -v -n

Haqiqiy mijoz sinovidan keyin nol paket soni moslik noto'g'ri ekanini bildiradi, tunnel buzilganini emas. Mos kela boshlagach, qoidalar to'plamini saqlang, u qayta yuklashga bardosh bersin; faqat shell tarixingizda yashaydigan tuzatish birinchi qayta yuklashda yo'qoladi.

Agar server bulutli NAT nusxasi ham bo'lsa, platformaning ham so'zi bor. Manzillarni tarjima qiladigan nusxa odatda provayder bu sozlamani taklif qiladigan joyda manba va manzil tekshiruvini o'chirib qo'yishni talab qiladi, VPN portining o'zi esa tashqaridan kirish imkoniyatiga ega bo'lishi kerak.

DNS — birinchisining orqasidagi ikkinchi muvaffaqiyatsizlik

Nomlar muvaffaqiyatsiz bo'lganda manzil bo'yicha ping ishlashi — hal qiluvchi muammosi, va uning o'z sababi bor. Mahalliy hal qiluvchisini saqlaydigan mijoz bu so'rovlarni to'liq tunnelga yuboradi va hech qachon kelmaydigan javobni kutadi, chunki mahalliy hal qiluvchi endi marshrutning noto'g'ri tomonida.

Mijoz qayerdan so'rashni bilishi uchun serverdan hal qiluvchi yuboring. Ikki yozuv birinchisi yetib bormasa, mijozga alternativa beradi, va ikkalasi ham tunnel haqiqatan ruxsat beradigan hal qiluvchilar bo'lishi kerak.

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

Windows mijozlari keyin baribir mahalliy hal qiluvchiga qaytishi mumkin, va block-outside-dns aynan shuni oldini olish uchun bor, lekin faqat mahalliy tarmoq hal qila oladigan nomlarni yo'qotish evaziga. systemd-resolved ishlatadigan Linux mijozlar skript o'rnatmasa, yuborilgan hal qiluvchini ko'pincha e'tiborsiz qoldiradi, shuning uchun yuborish e'tiborsiz qoldi degan xulosaga kelishdan oldin tunnel qurilmasi uchun resolvectl status ni tekshiring.

Sayohatni foydalanuvchi his qilganidek yakunlang. Mijozdan haqiqiy sahifani yuklang, u qaysi manzildan chiqishini tasdiqlang, serverni qayta yuklang, qayta ulanib, uchta sinovni takrorlang. Faqat o'sha ikkinchi aylanish saqlangan qoidalar, xavfsizlik devori siyosati va yuborilgan hal qiluvchi hammasi birga omon qolganini isbotlaydi.

O'xshash maqolalar