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

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