webpack ishlab chiqish serverini VPN manzilida qanday xizmat qilish kerak

Faqat noutbukda javob beradigan va boshqa joyda javob bermaydigan ishlab chiqish serveri odatda noto'g'ri manzilga bog'langan bo'ladi. Ulanishni qabul qiladigan, lekin sahifani rad etadigan server odatda host nomini tekshirishda muvaffaqiyatsizlikka uchraydi. Bular turli nosozliklar va turli tuzatishlar, to'g'ri konfiguratsiyani tanlash esa ish maydoniga kim yetib borishi va qanday yetib borishiga bog'liq.

Uch savol javobni belgilaydi: kim ulanadi, u qaysi manzilga yeta oladi va u uchun jonli qayta yuklash ishlashi kerakmi.

Konfiguratsiya faylidan emas, soketdan boshlang

Ishlayotgan jarayon aslida nimaga bog'langanini uni ishga tushirgan o'sha tarmoq kontekstida o'qing, chunki konteyner yoki nomlar maydoni host qobig'i ko'rmaydigan soketga ega bo'lishi mumkin. Tinglash ustuni birinchi savolga javob beradi: faqat mahalliy yo'l, bitta aniq interfeys yoki barcha interfeyslar.

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

Loopback manzili xavfsiz standart va masofaviy mijoz uchun foydasiz. Joker belgili bog'lash qulay va marshruti bor har bir interfeysda portni ochadi, bu esa tunnel ham olib yuradigan mashinada ko'pchilik niyat qilganidan kengroq. Aniq manzil o'rta variant bo'lib, u faqat soket yaratilgan paytda interfeys o'sha manzilga ega bo'lsa ishlaydi. Farq muhim, chunki bu uch bog'lashdan ikkitasi brauzerda bir xil ko'rinadi va ikkinchi interfeys paydo bo'lishi bilan butunlay boshqacha harakat qiladi.

Marshrutlar yoki firewall qoidalariga tegishdan oldin shu kuzatuvga moslashing. Agar jarayon noto'g'ri manzilda tinglayotgan bo'lsa, hech qanday siyosat marshrutlash mijozni u yerga yetkaza olmaydi.

Bog'lash manzilini unga kim yetib borishi kerakligiga qarab tanlang

Agar bu mashinada faqat sizga sahifa kerak bo'lsa, loopback bog'lashni saqlang va to'xtang. Agar o'sha tunneldagi bir hamkasbga kerak bo'lsa, tunnel interfeysining manzilini bog'lang va firewall faqat o'sha manbaga ruxsat bersin. Ishlab chiqish serverini uni faol sinovdan o'tkazayotganlardan tashqarida e'lon qilish — bu oxir-oqibat ish maydonini internetga ochib qo'yadigan odat.

Agar konteyner ichidagi brauzer serverga yetib borishi kerak bo'lsa, bog'lash manzili konteyner tarmog'i marshrutlay oladigan manzil bo'lishi kerak, va bu ko'pincha host o'zi uchun hal qiladigan manzil emas. Konfiguratsiyani tahrirlashdan oldin holatni hal qiling, chunki uch holat uch xil qiymat beradi va faqat bittasi to'g'ri. Bu yerda taxmin qilish sozlashning boshqa qismidan ko'ra ko'proq vaqt yo'qotadi.

So'ng manzilni ishga tushirgichingiz aslida o'qiydigan shaklda o'rnating. Konfiguratsiya fayli va serverni programmatik tarzda quradigan skript bir xil parametrlarni iste'mol qilmaydi:

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

O'sha parchadagi manzil misol bo'lib, host egalik qiladigan VPN manzilini bildiradi. Agar loyiha serverni new WebpackDevServer(options, compiler) bilan quradigan bo'lsa, parametrlarni uning o'rniga konstruktor argumenti orqali bering, chunki webpack konfiguratsiyasidagi alohida devServer xususiyati bu yo'lda hisobga olinmaydi. Konfiguratsiya fayli va Node API o'rtasidagi bu farq parchani hech qachon o'qimaydigan loyihaga ko'chirganlarni ushlaydi. dev-server hujjatlari ikki ishga tushirish uslubini ajratadi va foydalanilayotgan versiya bilan solishtirish kerak bo'lgan manba hisoblanadi.

Host nomini tekshirishni siz ma'qullagan nomlarga moslang

Host nomini tekshirish hujumchi nazorat qiladigan nomdan taqdim etilgan sahifa brauzer orqali sizning ishlab chiqish serveringiz bilan gaplashmasligi uchun mavjud. Uni allowedHosts: "all" bilan o'chirish bu himoyani olib tashlaydi va ichki xizmatlarga yeta oladigan mashinada bu qulaylik kamdan-kam arziydi. Brauzer qaysi nomlarni yuborishini bilganingizdan so'ng tekshirishni to'g'ri qondirish arzon.

Ishlatadigan aniq nomlarni, tunnel manziliga hal qilinadigan shaxsiy nomni ham qo'shib, sanab chiqing. Agar mijoz nomni siz bog'lagan manzildan boshqa manzilga hal qilsa, sizda nom hal qilish muammosi bor, server konfiguratsiyasi muammosi emas, va nomni ruxsat ro'yxatiga qo'shish buni tuzatmaydi. Hal qilishni serverdan emas, mijozdan tasdiqlang.

Uch boshqaruvni xayolingizda alohida saqlang: bog'lash manzili qaysi interfeyslar ulanishni qabul qilishini hal qiladi, ruxsat ro'yxati qaysi Host sarlavhalari qabul qilinishini hal qiladi, autentifikatsiya esa kimga kirishga ruxsat berilishini hal qiladi. Faqat uchinchisi kirishni boshqarish, ishlab chiqish serverida esa odatda hech biri yo'q. Tunnel manzili ham autentifikatsiya mexanizmi emas, chunki u yerga marshrutlay oladigan har kim siz tayangan chegaraning ichida allaqachon.

Sahifa va jonli qayta yuklash soketini birga tekshiring

Mo'ljallangan mijozdan sozlangan sxema bilan yangi so'rov yuklang va keshlash emas, natijani o'qing. HTTPS uchun kutilgan host nomi va sertifikat tekshiruvini saqlang, chunki brauzer ogohlantirishi muvaffaqiyatli qabul sinovi emas. Jonli qayta yuklash jimgina muvaffaqiyatsiz bo'layotganda sahifaning ko'rsatilishi bu yerda eng keng tarqalgan qisman muvaffaqiyat va tez tekshiruv paytida uni o'tkazib yuborish oson.

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

So'ng brauzerning tarmoq diagnostikasini oching va WebSocket ulanishini kuzating. Sahifa bir host nomi, port va sxema orqali yuklanishi mumkin, qayta yuklash soketi esa boshqasidan foydalanadi, shuning uchun ikkalasini alohida tekshirish kerak. Hujjatlashtirilgan mijoz URL manzilini faqat joylashtirilgan yo'l haqiqatan boshqa qiymatni talab qilganda sozlang va mijozga aylanma yo'lni o'rgatishdan ko'ra yo'lni tuzatishni afzal ko'ring.

Tinglovchi manzilini, qabul qilingan nomni, ruxsat etilgan manbani va ikkala natijani loyiha yozuvlariga qayd eting. Bu yozuv ish maydonini ishga tushirib, sahifa nima uchun yuklanadi-yu hech qachon yangilanmaydi deb hayron bo'ladigan keyingi odamga qoladi.