Як розмістити сервер розробки webpack на адресі VPN

Виберіть адресу прив'язки за тим, хто має дістатися до сервера розробки, потім обмежте перевірку імені хоста й переконайтеся, що і сторінка, і сокет живої перезавантаження підключаються.

Сервер розробки, який відповідає на ноутбуці й ніде більше, зазвичай прив'язаний до неправильної адреси. Сервер, який приймає з'єднання, але відмовляє у сторінці, зазвичай не проходить перевірку імені хоста. Це різні несправності з різними виправленнями, і вибір правильної конфігурації залежить від того, хто має дістатися до робочого простору і як він туди потрапляє.

Відповідь визначають три питання: хто підключається, якої адреси він може досягти і чи має для нього працювати живе перезавантаження.

Почніть із сокета, а не з файлу конфігурації

Прочитайте, до чого насправді прив'язаний робочий процес, у тому самому мережевому контексті, який його запустив, бо контейнер або простір імен може володіти сокетом, якого оболонка хоста не бачить. Стовпець прослуховування відповідає на перше питання: лише локальний шлях, один конкретний інтерфейс або всі інтерфейси.

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

Адреса петлі є безпечним значенням за замовчуванням і марна для віддаленого клієнта. Прив'язка до підстановки зручна й відкриває порт на кожному інтерфейсі, що має маршрут, а це ширше, ніж більшість людей має на увазі на машині, яка також несе тунель. Конкретна адреса — середній варіант, і він працює лише тоді, коли інтерфейс володіє цією адресою в момент створення сокета. Різниця важлива, бо дві з цих трьох прив'язок виглядають у браузері однаково й поводяться зовсім інакше, щойно з'являється другий інтерфейс.

Зважайте на це спостереження, перш ніж чіпати маршрути або правила брандмауера. Якщо процес слухає неправильну адресу, жодна маршрутизація за політиками не доведе клієнта до неї.

Виберіть адресу прив'язки за тим, хто має до неї дістатися

Якщо сторінка потрібна лише вам на цій машині, залиште прив'язку до петлі й зупиніться. Якщо вона потрібна одному колезі в тому самому тунелі, прив'яжіть адресу інтерфейсу тунелю й дозвольте брандмауеру пропускати лише це джерело. Публікація сервера розробки за межами тих, хто активно його тестує — це звичка, яка зрештою відкриває робочий простір інтернету.

Якщо браузеру всередині контейнера треба дістатися до сервера, адреса прив'язки має бути такою, куди мережа контейнера вміє маршрутизувати, і це часто не та адреса, яку хост розв'язує для себе. Вирішіть випадок до редагування конфігурації, бо три випадки дають три різні значення й лише одне правильне. Здогади тут марнують більше часу, ніж будь-яка інша частина налаштування.

Потім задайте адресу у формі, яку ваш лаунчер справді читає. Файл конфігурації та скрипт, який будує сервер програмно, не споживають одних і тих самих параметрів:

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

Адреса в цьому фрагменті ілюстративна й означає адресу VPN, якою володіє хост. Якщо проєкт будує сервер за допомогою new WebpackDevServer(options, compiler) передайте параметри через аргумент конструктора, бо окрема властивість devServer у конфігурації webpack на цьому шляху не розглядається. Ця різниця між файлом конфігурації та Node API ловить тих, хто копіює фрагмент у проєкт, який його ніколи не читає. Документація dev-server розділяє два стилі запуску й є довідкою, з якою треба порівнювати використану версію.

Узгодьте перевірку імені хоста з іменами, які ви схвалюєте

Перевірка імені хоста існує, щоб сторінка, віддана з імені, контрольованого зловмисником, не могла через браузер говорити з вашим сервером розробки. Вимкнення її за допомогою allowedHosts: "all" знімає цей захист, і зручність рідко того варта на машині, яка може дістатися внутрішніх служб. Перевірку дешево задовольнити правильно, коли ви знаєте, які імена надішле браузер.

Перелічіть точні імена, які будете використовувати, включно з приватним ім'ям, що розв'язується в адресу тунелю. Якщо клієнт розв'язує ім'я в іншу адресу, ніж та, до якої ви прив'язалися, у вас проблема розв'язання імен, а не конфігурації сервера, і додавання імені до списку дозволених це не виправить. Підтвердьте розв'язання з боку клієнта, а не сервера.

Тримайте три контролі окремо в голові: адреса прив'язки вирішує, які інтерфейси приймають з'єднання, список дозволених вирішує, які заголовки Host приймаються, а автентифікація вирішує, кого впускають. Лише третій є контролем доступу, і сервер розробки зазвичай не має жодного. Адреса тунелю теж не є механізмом автентифікації, бо будь-хто, хто вміє маршрутизувати до неї, вже всередині межі, на яку ви покладалися.

Перевірте сторінку й сокет живої перезавантаження разом

Завантажте свіжий запит від потрібного клієнта з налаштованою схемою й читайте результат, а не кеш. Для HTTPS зберігайте очікуване ім'я хоста й перевірку сертифіката, бо попередження браузера не є успішним приймальним тестом. Сторінка, яка відображається, поки живе перезавантаження тихо не працює, тут найчастіший частковий успіх, і його легко пропустити під час швидкої перевірки.

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

Потім відкрийте мережеву діагностику браузера й спостерігайте за з'єднанням WebSocket. Сторінка може завантажуватися через одне ім'я хоста, порт і схему, поки сокет перезавантаження використовує інші, тому їх треба перевіряти окремо. Налаштовуйте документовану URL-адресу клієнта лише тоді, коли розгорнутий шлях справді потребує іншого значення, і віддавайте перевагу виправленню шляху, а не навчанню клієнта обхідному рішенню.

Запишіть адресу прослуховування, прийняте ім'я, дозволене джерело й обидва результати в нотатках проєкту. Цей запис переживе наступну людину, яка запустить робочий простір і дивуватиметься, чому сторінка завантажується, але ніколи не оновлюється.

Схожі статті