Как да стартирате 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 на клиента само когато разгърнатият път наистина се нуждае от различна стойност и предпочитайте да поправите пътя вместо да учите клиента на заобиколно решение.

Запишете адреса на слушача, приетото име, разрешения източник и двата резултата в бележките на проекта. Този запис остава за следващия човек, който стартира работното пространство и се чуди защо страницата се зарежда, но никога не се обновява.