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 мәнін тек орналастырылған жол шынымен басқа мәнді қажет еткенде конфигурациялаңыз, және клиентке айналма жолды үйретуден гөрі жолды түзетуді таңдаңыз.

Тыңдаушы мекенжайын, қабылданған атауды, рұқсат етілген көзді және екі нәтижені жоба жазбаларына тіркеңіз. Бұл жазба жұмыс кеңістігін іске қосып, бет неге жүктеледі деп, бірақ ешқашан жаңармайды деп таңырқайтын келесі адамға қалады.

Қатысты мақалалар