Како послужити 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 клијента само када распоређена путања заиста захтева другу вредност, и претпоставите исправљање путање учењу клијента заобилазном решењу.

Забележите адресу слушаоца, прихваћено име, дозвољени извор и оба резултата у белешкама пројекта. Тај запис остаје за следећу особу која покрене радни простор и запита се зашто се страница учитава али никада не освежава.

Повезани чланци