Як размясціць 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 кліента, толькі калі разгорнуты шлях сапраўды патрабуе іншага значэння, і аддавайце перавагу выпраўленню шляху замест навучання кліента абыходнаму прыёму.

Заняпішыце адрас слухача, прынятае імя, дазволеную крыніцу і абодва вынікі ў нататках праекта. Гэты запіс перажыве наступнага чалавека, які запусціць працоўную прастору і будзе здзіўляцца, чаму старонка загружаецца, але ніколі не абнаўляецца.

Падобныя артыкулы