webpack иштетүү серверин VPN дарегинде кантип тейлөө керек

Иштетүү серверине ким жетиши керек экенине жараша байлоо дарегин тандаңыз, андан кийин хост атын текшерүүнү чектеңиз жана барак менен түз кайра жүктөө сокетинин экөө тең туташканын ырастаңыз.

Ноутбукта жооп берген жана башка жерде жооп бербеген иштетүү сервери адатта туура эмес дарекке байланган. Туташууну кабыл алып, бирок баракты четке каккан сервер адатта хост атын текшерүүдөн өтпөйт. Бул ар башка бузулуулар жана ар башка оңдоолор, ал эми туура конфигурацияны тандоо иш мейкиндигине ким жетиши керек жана кантип жетет экенине байланыштуу.

Үч суроо жоопту аныктайт: ким туташат, ал кайсы дарекке жете алат жана ага түз кайра жүктөө иштеши керекпи.

Конфигурация файлынан эмес, сокеттен баштаңыз

Иштеп жаткан процесс чындыгында эмнеге байланганын аны иштеткен ошол эле тармактык контекстен окуңуз, анткени контейнер же аттар мейкиндиги хост кабыгы көрө албаган сокетке ээ болушу мүмкүн. Угуу мамычасы биринчи суроого жооп берет: тек жергиликтүү жол, бир конкреттүү интерфейс же бардык интерфейстер.

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

Loopback дареги коопсуз демейки жана алыскы кардар үчүн пайдасыз. Wildcard байлоо ыңгайлуу жана маршруту бар ар бир интерфейсте портту ачат, бул туннелди да алып жүргөн машинада көпчүлүк ойлогондон кененирээк. Конкреттүү дарек ортоңку вариант жана сокет түзүлгөн учурда интерфейс ошол дарекке ээ болсо гана иштейт. Айырмачылык маанилүү, анткени бул үч байлоонун экөө браузерде бирдей көрүнөт жана экинчи интерфейс пайда болгондо таптакыр башкача аракет кылат.

Маршруттарга же firewall эрежелерине тийүүдөн мурун ошол байкоого ылайыкташыңыз. Эгер процесс туура эмес даректи угуп жатса, эч кандай саясий маршруттоо кардарды ага жеткирбейт.

Байлоо дарегин ага ким жетиши керек экенине жараша тандаңыз

Эгер бул машинада сизге гана барак керек болсо, loopback байлоосун сактап, токтоңуз. Эгер ошол эле туннелдеги бир кесиптешке керек болсо, туннел интерфейсинин дарегин байлап, firewall тек ошол булакка уруксат берсин. Иштетүү серверин аны активдүү сынап жаткан адамдардан тышкары жарыялоо — бул иш мейкиндигин акыры интернетке ачып берүүчү адат.

Эгер контейнердин ичиндеги браузер серверге жетиши керек болсо, байлоо дареги контейнердин тармагы маршруттай алган дарек болушу керек, жана бул көбүнчө хост өзү үчүн чечкен дарек эмес. Конфигурацияны оңдоодон мурун учурду чечиңиз, анткени үч учур үч башка маани берет жана бирөө гана туура. Бул жерде божомолдоо орнотуунун каалаган башка бөлүгүнөн да көп убакыт жоготот.

Андан кийин даректи иштеткичиңиз чындыгында окуган формада коюңуз. Конфигурация файлы жана серверди программалык түрдө куруучу скрипт бирдей параметрлерди колдонбойт:

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

Ошол үзүндүдөгү дарек иллюстративдик жана хост ээлик кылган VPN дарегин билдирет. Эгер долбоор серверди new WebpackDevServer(options, compiler) аркылуу куруп жатса, параметрлерди анын ордуна конструктор аргументи аркылуу бериңиз, анткени webpack конфигурациясындагы өзүнчө devServer касиети бул жолдо каралбайт. Конфигурация файлы менен 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 дарегин орнотулган жол чындыгында башка маанини талап кылганда гана конфигурациялаңыз, жана кардарга айланып өтүү жолун үйрөтүүдөн жолду оңдоону артык көрүңүз.

Угуучунун дарегин, кабыл алынган атты, уруксат берилген булакты жана эки натыйжаны долбоордун жазууларына жазыңыз. Бул жазуу иш мейкиндигин иштетип, барак эмне үчүн жүктөлөт, бирок эч качан жаңырбайт деп таң калган кийинки адамга калат.

Тектеш макалалар