webpack inkişaf serverini VPN ünvanında necə təqdim etmək olar

Noutbukda cavab verən və başqa heç yerdə cavab verməyən inkişaf serveri adətən yanlış ünvana bağlanır. Bağlantını qəbul edən, lakin səhifəni rədd edən server isə adətən host adı yoxlamasından keçmir. Bunlar fərqli nasazlıqlar və fərqli düzəlişlərdir, düzgün konfiqurasiyanın seçimi isə iş sahəsinə kimin çatmalı olduğundan və oraya necə gəldiyindən asılıdır.

Cavabı üç sual müəyyən edir: kim qoşulur, hansı ünvana çata bilir və canlı yeniləmə onlar üçün işləməlidirmi.

Konfiqurasiya faylı ilə deyil, soketlə başlayın

İşləyən prosesin həqiqətən nəyə bağlandığını onu başladan şəbəkə kontekstinin içində oxuyun, çünki konteyner və ya ad məkanı host qabığının görə bilmədiyi soketə sahib ola bilər. Dinləmə sütunu birinci suala cavab verir: yalnız yerli yol, bir konkret interfeys və ya bütün interfeyslər.

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

Loopback ünvanı təhlükəsiz standartdır və uzaq müştəri üçün faydasızdır. Wildcard bağlaması rahatdır və portu marşrutu olan hər interfeysdə açır, bu isə tunel də daşıyan maşında çoxlarının nəzərdə tutduğundan daha genişdir. Konkret ünvan orta variantdır və yalnız soket yaradılan anda interfeys həmin ünvana sahibdirsə işləyir. Fərq vacibdir, çünki bu üç bağlamadan ikisi brauzerdə eyni görünür və ikinci interfeys yaranan kimi tamamilə fərqli davranır.

Marşrutlara və ya firewall qaydalarına toxunmazdan əvvəl bu müşahidəni uyğunlaşdırın. Proses yanlış ünvanda dinləyirsə, heç bir siyasət marşrutlaşdırması müştərini ora çatdırmayacaq.

Bağlama ünvanını ona kimin çatmalı olduğuna görə seçin

Səhifə yalnız bu maşındakı sizə lazımdırsa, loopback bağlamasını saxlayın və dayanın. Eyni tuneldəki bir həmkarınıza lazımdırsa, tunel interfeysinin ünvanını bağlayın və firewall yalnız o mənbəyə icazə versin. İnkişaf serverini onu aktiv sınaqdan keçirənlərdən kənara yayımlamaq iş sahəsini sonda internetə açan bir vərdişdir.

Konteyner içindəki brauzer serverə çatmalıdırsa, bağlama ünvanı konteynerin şəbəkəsinin marşrutlaşa bildiyi ünvan olmalıdır və bu çox vaxt hostun özü üçün həll etdiyi ünvan deyil. Konfiqurasiyanı redaktə etməzdən əvvəl halı müəyyənləşdirin, çünki üç hal üç fərqli dəyər verir və yalnız biri doğrudur. Burada təxmin etmək quraşdırmanın hər hansı digər hissəsindən daha çox vaxt itirir.

Sonra ünvanı başladıcınızın həqiqətən oxuduğu formada təyin edin. Konfiqurasiya faylı ilə serveri proqramlı şəkildə quran skript eyni seçimləri istehlak etmir:

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

Həmin fraqmentdəki ünvan nümunə üçündür və hostun sahib olduğu VPN ünvanını bildirir. Layihə serveri new WebpackDevServer(options, compiler), ilə qurursa, seçimləri bunun əvəzinə konstruktor arqumenti vasitəsilə ötürün, çünki ayrı devServer xassəsi webpack konfiqurasiyasında o yolda nəzərə alınmır. Konfiqurasiya faylı ilə Node API arasındakı bu fərq mətn parçasını heç vaxt oxumayan layihəyə köçürənləri tutur. dev-server sənədləri iki işə salma üslubunu ayırır və istifadə olunan versiya ilə yoxlanılmalı istinaddır.

Host adı yoxlamasını təsdiqlədiyiniz adlara uyğunlaşdırın

Host adı yoxlaması təcavüzkarın idarə etdiyi addan təqdim edilən səhifənin brauzer vasitəsilə inkişaf serverinizlə danışmasının qarşısını almaq üçün mövcuddur. Onu allowedHosts: "all" ilə söndürmək bu qorunmanı aradan qaldırır və rahatlıq daxili xidmətlərə çata bilən maşında buna nadir hallarda dəyər. Brauzerin hansı adları göndərəcəyini bildikdən sonra yoxlamanı düzgün ödəmək ucuzdur.

İstifadə edəcəyiniz dəqiq adları sadalayın, tunel ünvanına həll olunan şəxsi ad daxil olmaqla. Müştəri bir adı bağladığınız ünvandan fərqli ünvana həll edirsə, server konfiqurasiyası deyil, ad həlli problemi var və adı icazə siyahısına əlavə etmək bunu düzəltməyəcək. Həlli serverdən deyil, müştəridən təsdiqləyin.

Üç nəzarəti beyninizdə ayrı saxlayın: bağlama ünvanı hansı interfeyslərin bağlantını qəbul etdiyini, icazə siyahısı hansı Host başlıqlarının qəbul edildiyini, autentifikasiya isə kimin içəri buraxıldığını müəyyən edir. Yalnız üçüncüsü giriş nəzarətidir və inkişaf serverində adətən heç biri olmur. Tunel ünvanı da autentifikasiya mexanizmi deyil, çünki ona marşrutlaşa bilən hər kəs artıq güvəndiyiniz sərhədin içindədir.

Səhifəni və canlı yeniləmə soketini birlikdə yoxlayın

Nəzərdə tutulan müştəridən konfiqurasiya edilmiş sxemlə təzə sorğu yükləyin və keşi deyil, nəticəni oxuyun. HTTPS üçün gözlənilən host adını və sertifikat yoxlamasını saxlayın, çünki brauzer xəbərdarlığı uğurlu qəbul testi deyil. Canlı yeniləmə səssizcə uğursuz olarkən göstərilən səhifə burada ən çox rast gəlinən qismən uğurdur və sürətli yoxlama zamanı asanlıqla gözdən qaçır.

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

Sonra brauzerin şəbəkə diaqnostikasını açın və WebSocket bağlantısını izləyin. Səhifə bir host adı, port və sxem üzərindən yüklənə bilər, yeniləmə soketi isə başqasını istifadə edir, buna görə ikisi ayrıca yoxlanmalıdır. Sənədləşdirilmiş müştəri URL-ni yalnız yerləşdirilmiş yol həqiqətən fərqli dəyər tələb etdikdə konfiqurasiya edin və müştəriyə iş ətrafı öyrətməkdənsə yolu düzəltməyi üstün tutun.

Dinləyici ünvanını, qəbul edilən adı, icazə verilən mənbəyi və hər iki nəticəni layihə qeydlərində yazın. Bu qeyd iş sahəsini başladan və səhifənin niyə yükləndiyini, lakin heç vaxt yenilənmədiyini düşünən növbəti şəxs üçün qalır.