Ինչպես webpack զարգացման սերվերը սպասարկել VPN հասցեով

Զարգացման սերվերը, որը պատասխանում է նոութբուքի վրա և ոչ մի այլ տեղ, սովորաբար կապված է սխալ հասցեին։ Սերվերը, որը ընդունում է կապը, բայց մերժում է էջը, սովորաբար ձախողվում է հոսթանվան ստուգման ժամանակ։ Դրանք տարբեր խափանումներ են՝ տարբեր ուղղումներով, և ճիշտ կոնֆիգուրացիայի ընտրությունը կախված է նրանից, թե ով պետք է հասնի աշխատանքային տարածքին և ինչպես է հասնում։

Երեք հարց որոշում են պատասխանը՝ ով է միանում, որ հասցեին կարող է հասնել և արդյոք ուղիղ վերաբեռնումը պետք է աշխատի նրա համար։

Սկսեք սոքեթից, ոչ թե կոնֆիգուրացիայի ֆայլից

Կարդացեք, թե ինչին է իրականում կապված գործող պրոցեսը՝ նույն ցանցային համատեքստում, որը գործարկել է այն, որովհետև կոնտեյները կամ անվանատարածքը կարող է տիրապետել սոքեթի, որը հոսթի shell-ը չի տեսնում։ Լսելու սյունակը պատասխանում է առաջին հարցին՝ միայն տեղական ուղի, մեկ կոնկրետ ինտերֆեյս կամ բոլոր ինտերֆեյսները։

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)-ով, ապա ընտրանքները փոխանցեք կոնստրուկտորի արգումենտով, որովհետև առանձին 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-ը միայն այն դեպքում, երբ տեղակայված ուղին իսկապես այլ արժեք է պահանջում, և նախընտրեք ուղղել ուղին, քան կլիենտին շրջանցում սովորեցնել։

Գրանցեք լսողի հասցեն, ընդունված անունը, թույլատրված աղբյուրը և երկու արդյունքները նախագծի նշումներում։ Այդ գրառումը կմնա հաջորդ մարդու համար, ով կգործարկի աշխատանքային տարածքը և կմտածի, թե ինչու էջը բեռնվում է, բայց երբեք չի թարմացվում։