Cara menyediakan pelayan pembangunan webpack pada alamat VPN

Pelayan pembangunan yang menjawab pada komputer riba dan tidak di tempat lain biasanya terikat pada alamat yang salah. Pelayan yang menerima sambungan tetapi menolak halaman biasanya gagal semakan nama hos. Itu kerosakan berbeza dengan pembetulan berbeza, dan memilih konfigurasi yang betul bergantung pada siapa yang perlu mencapai ruang kerja dan bagaimana mereka tiba.

Tiga soalan menentukan jawapannya: siapa yang bersambung, alamat mana yang boleh mereka capai, dan sama ada muat semula langsung perlu berfungsi untuk mereka.

Mulakan dengan soket, bukan fail konfigurasi

Baca apa yang sebenarnya diikat oleh proses yang berjalan dalam konteks rangkaian yang sama yang memulakannya, kerana kontena atau ruang nama boleh memiliki soket yang tidak dapat dilihat oleh shell hos. Lajur mendengar menjawab soalan pertama: hanya laluan tempatan, satu antara muka tertentu, atau setiap antara muka.

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

Alamat gelung balik ialah lalai yang selamat dan tidak berguna kepada klien jauh. Pengikatan kad liar adalah mudah dan mendedahkan port pada setiap antara muka yang mempunyai laluan, yang lebih luas daripada yang dimaksudkan kebanyakan orang pada mesin yang juga membawa terowong. Alamat tertentu ialah pilihan tengah, dan ia hanya berfungsi jika antara muka memiliki alamat itu pada saat soket dicipta. Perbezaan itu penting kerana dua daripada tiga pengikatan itu kelihatan sama dalam pelayar dan berkelakuan sama sekali berbeza apabila antara muka kedua wujud.

Selaraskan dengan pemerhatian itu sebelum menyentuh laluan atau peraturan tembok api. Jika proses mendengar pada alamat yang salah, tiada penghalaan dasar akan membawa klien ke sana.

Pilih alamat pengikatan mengikut siapa yang perlu mencapainya

Jika hanya anda pada mesin ini memerlukan halaman itu, kekalkan pengikatan gelung balik dan berhenti. Jika seorang rakan sekerja pada terowong yang sama memerlukannya, ikat alamat antara muka terowong dan biarkan tembok api hanya membenarkan sumber itu. Menerbitkan pelayan pembangunan di luar kalangan orang yang mengujinya secara aktif ialah tabiat yang akhirnya mendedahkan ruang kerja kepada internet.

Jika pelayar di dalam kontena perlu mencapai pelayan, alamat pengikatan mesti satu yang boleh dihalakan oleh rangkaian kontena, dan itu selalunya bukan alamat yang diselesaikan oleh hos untuk dirinya sendiri. Tentukan kes itu sebelum mengedit konfigurasi, kerana tiga kes menghasilkan tiga nilai berbeza dan hanya satu yang betul. Meneka di sini membuang lebih banyak masa daripada mana-mana bahagian persediaan yang lain.

Kemudian tetapkan alamat dalam bentuk yang benar-benar dibaca oleh pelancar anda. Fail konfigurasi dan skrip yang membina pelayan secara program tidak menggunakan pilihan yang sama:

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

Alamat dalam serpihan itu adalah ilustrasi dan mewakili alamat VPN yang dimiliki oleh hos. Jika projek membina pelayan dengan new WebpackDevServer(options, compiler) salurkan pilihan melalui argumen pembina sebaliknya, kerana sifat berasingan devServer dalam konfigurasi webpack tidak dirujuk pada laluan itu. Perbezaan itu antara fail konfigurasi dan Node API menangkap orang yang menyalin serpihan ke dalam projek yang tidak pernah membacanya. dokumentasi dev-server memisahkan dua gaya pelancaran dan merupakan rujukan untuk membandingkan versi yang digunakan.

Padankan semakan nama hos dengan nama yang anda luluskan

Semakan nama hos wujud untuk menghalang halaman yang disampaikan daripada nama yang dikawal penyerang daripada bercakap dengan pelayan pembangunan anda melalui pelayar. Melumpuhkannya dengan allowedHosts: "all" membuang perlindungan itu, dan kemudahan itu jarang berbaloi pada mesin yang boleh mencapai perkhidmatan dalaman. Semakan itu murah untuk dipenuhi dengan betul setelah anda tahu nama mana yang akan dihantar oleh pelayar.

Senaraikan nama tepat yang akan anda gunakan, termasuk nama peribadi yang diselesaikan kepada alamat terowong. Jika klien menyelesaikan nama kepada alamat yang berbeza daripada yang anda ikat, anda mempunyai masalah penyelesaian nama dan bukan masalah konfigurasi pelayan, dan menambah nama itu ke senarai dibenarkan tidak akan membetulkannya. Sahkan penyelesaian daripada klien, bukan daripada pelayan.

Simpan ketiga-tiga kawalan secara berasingan dalam fikiran anda: alamat pengikatan menentukan antara muka mana yang menerima sambungan, senarai dibenarkan menentukan pengepala Host mana yang diterima, dan pengesahan menentukan siapa yang dibenarkan masuk. Hanya yang ketiga ialah kawalan akses, dan pelayan pembangunan biasanya tidak mempunyai sebarang. Alamat terowong juga bukan mekanisme pengesahan, kerana sesiapa yang boleh menghalakan ke sana sudah berada di dalam sempadan yang anda bergantung padanya.

Sahkan halaman dan soket muat semula langsung bersama-sama

Muatkan permintaan baharu daripada klien yang dimaksudkan dengan skema yang dikonfigurasikan, dan baca hasilnya dan bukan cache. Untuk HTTPS, kekalkan nama hos yang dijangka dan pengesahan sijil, kerana amaran pelayar bukan ujian penerimaan yang berjaya. Halaman yang dipaparkan sementara muat semula langsung gagal secara senyap ialah kejayaan separa yang paling biasa di sini, dan mudah terlepas semasa semakan pantas.

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

Kemudian buka diagnostik rangkaian pelayar dan perhatikan sambungan WebSocket. Halaman boleh dimuatkan melalui satu nama hos, port dan skema sementara soket muat semula menggunakan yang lain, itulah sebabnya kedua-duanya mesti disemak secara berasingan. Konfigurasikan URL klien yang didokumenkan hanya apabila laluan yang digunakan benar-benar memerlukan nilai berbeza, dan utamakan membaiki laluan daripada mengajar klien penyelesaian sementara.

Catatkan alamat pendengar, nama yang diterima, sumber yang dibenarkan dan kedua-dua hasil dalam nota projek. Rekod itu kekal untuk orang seterusnya yang memulakan ruang kerja dan tertanya-tanya mengapa halaman dimuatkan tetapi tidak pernah dimuat semula.