PiVPN qo'l berish jarayoni ishlaydi, sahifalar muzlaydi: MASQUERADE ni tekshiring
Qo'l berish tugaydi, lekin sahifalar muzlayaptimi? Saqlangan MASQUERADE qoidasi noto'g'ri yuqori kanalni ko'rsatadi. NAT jadvalini o'qing, interfeysni tuzating, so'ng hisoblagichlar bilan isbotlang.
Telefoningiz tunnelni ulangan deb ko'rsatadi, mijoz xususiy manzil haqida xabar beradi, lekin birinchi sahifa hamon yuklanish o'rtasida osilib turadi. Bu birikma ko'pchilikni shifr sozlamalari va protsessor haroratiga yo'naltiradi, holbuki u yerda aslida hech narsa buzilmagan. Tunnel ko'tarildi, demak muzokaralar tugadi; muvaffaqiyatsiz bo'lgani keyingi qadam, server mijoz paketlarini internetga topshirishga urinayotganda. Shu paketlar yuradigan yo'ldan yuring, va nomuvofiqlik odatda NAT jadvalining bitta satrida ko'rinadi.
Mijoz nimaga yeta olishi va yeta olmasligidan boshlang
Ulangan mijozdan ochiq internetda joylashgan sahifani yuklang va u darhol barbod bo'ladimi yoki o'rtada muzlaydimi, qayd eting. So'ng VPN serverining o'z xususiy manzilidagi resursni oching va ikkala natijani solishtiring.
Ochiq saytlar vaqti tugayotganda ping ga javob beradigan tunnel manzili — bu yo'naltirish yoki tarjima muammosi belgisi, buzilgan qo'l berish emas. Mijozning o'z holat paneli ikkalasini ajrata olmaydi, chunki u faqat boshqaruv kanali ko'tarilganini biladi. Serverda tunnel interfeysini shu bilan tekshiring: ip -br addr show tun0 va mijozga berilgan manzil siz sozlagan hovuz ichida ekanini tasdiqlang. Agar hovuz va mijoz manzili mos kelmasa, avval shuni tuzating, chunki quyidagi har bir qoida hovuzga moslanadi.
Keyin serverdan ochiq manzilga yetish uchun qaysi interfeysdan foydalanishini so'rang. ip route get 203.0.113.9 birinchi satrida tanlangan qurilma va manbani chop etadi. Shu qurilma nomini yozib qo'ying, chunki NAT qoidasida aynan shu qiymat bo'lishi kerak.
Paketlar chiqishini hal qiladigan qoidani o'qing
MASQUERADE paketni faqat qoidada nomlangan interfeys orqali chiqqanda qayta yozadi. Simli qurilmaga bog'langan qoida Wi-Fi orqali chiqadigan trafik uchun hech narsa qilmaydi, va paket o'z xususiy manba manzilini yuqori routergacha saqlaydi. Bu routerda sizning tunnel hovuzingizga qaytish yo'li yo'q, shuning uchun u javobni tashlab yuboradi, va mijoz ochilib keyin o'ladigan ulanishni ko'radi. Alomat birinchi javob kerak bo'lishidan oldin sahifaning qancha qismi yetib kelishiga qarab o'sadi.
Jonli jadvalni ro'yxatlang va faqat MASQUERADE so'zini izlash o'rniga chiqish interfeysi ustunini o'qing. Qo'shish shaklidagi chiqishni formatlangan ro'yxatdan solishtirish osonroq:
ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING
Bir vaqtlar Ethernet, endi Wi-Fi ishlatadigan Raspberry Pi da eskirgan nom deyarli har doim butun voqea. O'rnatuvchi sozlash paytida qaysi qurilma borligini yozib olgan, va saqlangan qoidalar to'plami uni har yuklashda qayta o'ynatadi. Boshqa narsani o'zgartirishdan oldin marshrut qidiruvidan chiqqan qurilmani qoidadagi qurilma bilan solishtiring. Agar ular mos kelsa, interfeys sizning muammoingiz emas va oxirgi bo'limdagi hisoblagichlarga o'tishingiz kerak. Agar farq qilsa, tuzatish — saqlash faylidagi bitta so'zni tahrirlash.
Saqlangan qoidalar to'plamini tuzating, faqat ishlab turganini emas
Faqat jonli jadvalni tahrirlash keyingi qayta yuklashgacha davom etadi, bu esa muammo hal bo'ldi deb sizni ishontirish uchun yetarli. Yuklash paytida qaytadigan qoidalar o't o'chirish tizimining saqlash paketi qayta yuklaydigan faylda yashaydi. Debian asosidagi Pi obrazlarida bu fayl odatda /etc/iptables/rules.v4.
Unga tegishdan oldin nusxa oling, so'ng MASQUERADE satridagi chiqish interfeysini yozib olgan qurilmangiz bilan almashtiring, masalan -o wlan0 o'rniga -o eth0. Mijoz hovuzingiz o'zgarmagan bo'lsa, manba diapazonini o'z holicha qoldiring. Qayta yuklang va qoida endi to'g'ri qurilmani ko'rsatishini tasdiqlang:
sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n
Yonma-yon ikki sozlamani unutish oson. sysctl net.ipv4.ip_forward 1 ni xabar qilishi kerak, va yuqori router xususiy manba manzillarini o'zi filtrlamasligi kerak.
Qoida ishga tushishini isbotlang, so'ng hali nima sekin ekanini ajratib oling
Hisoblagichlar qoida mos kelganining yagona halol isbotidir. Batafsil ro'yxatni ishga tushiring, mijozda yuklab olishni boshlang va yana ishga tushiring. Qoidangiz yonidagi paket va bayt ustunlari o'sishi kerak, nolda qolgan qoida esa hali mos kelmaydi. Hisoblagichlar qimirlasa ham sahifalar barbod bo'lsa, manba diapazonini haqiqiy hovuz bilan shu orqali solishtiring grep -n "^server " /etc/openvpn/server.conf. Ular qimirlab sahifalar yuklansa-yu, o'tkazish qobiliyati past bo'lsa, tarjima tugagan va qolgan muammo boshqa joyda.
Bir mijozdan ikkita uzatishni solishtiring: biri mahalliy tarmoqdagi hostga, ikkinchisi tunnel orqali o'sha hostga. Ikkalasida ham sekinlik VPN ga emas, Pi ning yuqori kanaliga yoki Wi-Fi ulanishiga ishora qiladi. Faqat tunnel orqali sekinlik MTU va qayta uzatishlarga ishora qiladi, ularni shu bilan ko'zdan kechirish mumkin ip -s link show tun0 har qanday shifr sozlamasini o'zgartirishdan oldin.
Tajribani bekor qilish uchun nusxani tiklang va qayta yuklang, so'ng asl qoida va uning hisoblagichlari qaytganini tasdiqlang. Chiqish qurilmasi va qayta yuklash buyrug'ini server eslatmalariga yozing, chunki keyingi yuqori kanal o'zgarishi o'sha nomuvofiqlikni yana kashf etadi. Noto'g'ri qurilmani ko'rsatgan qoida trafik unga muhtoj bo'lmaguncha ko'rinmay qoladi.