Cara menyajikan server pengembangan webpack di alamat VPN

Server pengembangan yang menjawab di laptop dan tidak di tempat lain biasanya terikat ke alamat yang salah. Server yang menerima koneksi tetapi menolak halaman biasanya gagal dalam pemeriksaan nama host. Keduanya adalah kesalahan yang berbeda dengan perbaikan yang berbeda, dan memilih konfigurasi yang tepat bergantung pada siapa yang harus menjangkau ruang kerja dan bagaimana mereka tiba.

Tiga pertanyaan menentukan jawabannya: siapa yang terhubung, alamat mana yang dapat mereka jangkau, dan apakah muat ulang langsung harus bekerja bagi mereka.

Mulai dari soket, bukan dari file konfigurasi

Baca apa yang sebenarnya diikat oleh proses yang berjalan di dalam konteks jaringan yang sama yang memulainya, karena kontainer atau ruang nama dapat memiliki soket yang tidak dapat dilihat oleh shell host. Kolom mendengarkan menjawab pertanyaan pertama: hanya jalur lokal, satu antarmuka tertentu, atau setiap antarmuka.

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

Alamat loopback adalah default yang aman dan tidak berguna bagi klien jarak jauh. Pengikatan wildcard nyaman dan mengekspos port pada setiap antarmuka yang memiliki rute, yang lebih luas daripada yang dimaksudkan kebanyakan orang pada mesin yang juga membawa terowongan. Alamat tertentu adalah opsi tengah, dan hanya berfungsi jika antarmuka memiliki alamat itu pada saat soket dibuat. Perbedaannya penting karena dua dari tiga pengikatan itu terlihat identik di peramban dan berperilaku sangat berbeda begitu ada antarmuka kedua.

Sesuaikan dengan pengamatan itu sebelum menyentuh rute atau aturan firewall. Jika proses mendengarkan di alamat yang salah, tidak ada perutean kebijakan yang akan membuat klien menjangkaunya.

Pilih alamat pengikatan berdasarkan siapa yang harus menjangkaunya

Jika hanya Anda di mesin ini yang memerlukan halaman, pertahankan pengikatan loopback dan berhenti. Jika satu rekan di terowongan yang sama memerlukannya, ikat alamat antarmuka terowongan dan biarkan firewall hanya mengizinkan sumber itu. Menerbitkan server pengembangan di luar orang-orang yang secara aktif mengujinya adalah kebiasaan yang akhirnya mengekspos ruang kerja ke internet.

Jika peramban di dalam kontainer perlu menjangkau server, alamat pengikatan harus salah satu yang dapat dirutekan oleh jaringan kontainer, dan itu sering kali bukan alamat yang diselesaikan host untuk dirinya sendiri. Tentukan kasusnya sebelum mengedit konfigurasi, karena tiga kasus menghasilkan tiga nilai berbeda dan hanya satu yang benar. Menebak di sini membuang lebih banyak waktu daripada bagian lain dari penyiapan.

Lalu atur alamat dalam bentuk yang benar-benar dibaca oleh peluncur Anda. File konfigurasi dan skrip yang membangun server secara programatik tidak mengonsumsi opsi yang sama:

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

Alamat dalam fragmen itu bersifat ilustratif dan mewakili alamat VPN yang dimiliki host. Jika proyek membangun server dengan new WebpackDevServer(options, compiler) lewati opsi melalui argumen konstruktor sebagai gantinya, karena properti terpisah devServer dalam konfigurasi webpack tidak diperiksa pada jalur itu. Perbedaan itu antara file konfigurasi dan Node API menangkap orang yang menyalin potongan ke proyek yang tidak pernah membacanya. dokumentasi dev-server memisahkan dua gaya peluncuran dan merupakan referensi untuk memeriksa versi yang digunakan.

Cocokkan pemeriksaan nama host dengan nama yang Anda setujui

Pemeriksaan nama host ada untuk mencegah halaman yang disajikan dari nama yang dikendalikan penyerang berbicara dengan server pengembangan Anda melalui peramban. Menonaktifkannya dengan allowedHosts: "all" menghapus perlindungan itu, dan kemudahannya jarang sepadan pada mesin yang dapat menjangkau layanan internal. Pemeriksaan itu murah untuk dipenuhi dengan benar setelah Anda tahu nama mana yang akan dikirim peramban.

Daftarkan nama persis yang akan Anda gunakan, termasuk nama privat yang diselesaikan ke alamat terowongan. Jika klien menyelesaikan nama ke alamat yang berbeda dari yang Anda ikat, Anda memiliki masalah resolusi nama, bukan masalah konfigurasi server, dan menambahkan nama ke daftar izin tidak akan memperbaikinya. Konfirmasikan resolusi dari klien, bukan dari server.

Jaga ketiga kontrol tetap terpisah di kepala Anda: alamat pengikatan menentukan antarmuka mana yang menerima koneksi, daftar izin menentukan header Host mana yang diterima, dan autentikasi menentukan siapa yang boleh masuk. Hanya yang ketiga adalah kontrol akses, dan server pengembangan biasanya tidak memilikinya. Alamat terowongan juga bukan mekanisme autentikasi, karena siapa pun yang dapat merutekan ke sana sudah berada di dalam batas yang Anda andalkan.

Verifikasi halaman dan soket muat ulang langsung bersama-sama

Muat permintaan baru dari klien yang dimaksudkan dengan skema yang dikonfigurasi, dan baca hasilnya alih-alih cache. Untuk HTTPS, pertahankan nama host yang diharapkan dan validasi sertifikat, karena peringatan peramban bukan uji penerimaan yang berhasil. Halaman yang ditampilkan sementara muat ulang langsung gagal diam-diam adalah keberhasilan parsial paling umum di sini, dan mudah terlewat saat pemeriksaan cepat.

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

Lalu buka diagnostik jaringan peramban dan amati koneksi WebSocket. Halaman dapat dimuat melalui satu nama host, port, dan skema sementara soket muat ulang menggunakan yang lain, itulah sebabnya keduanya harus diperiksa secara terpisah. Konfigurasikan URL klien yang didokumentasikan hanya ketika jalur yang diterapkan benar-benar membutuhkan nilai berbeda, dan utamakan memperbaiki jalur daripada mengajari klien solusi sementara.

Catat alamat pendengar, nama yang diterima, sumber yang diizinkan, dan kedua hasil di catatan proyek. Catatan itu bertahan bagi orang berikutnya yang memulai ruang kerja dan bertanya-tanya mengapa halaman dimuat tetapi tidak pernah menyegarkan.