Kā apkalpot webpack izstrādes serveri VPN adresē

Izvēlieties saistīšanas adresi pēc tā, kam jāsasniedz izstrādes serveris, pēc tam sašauriniet resursdatora nosaukuma pārbaudi un apstipriniet, ka gan lapa, gan tiešās pārlādes ligzda savienojas.

Izstrādes serveris, kas atbild uz klēpjdatora un nekur citur, parasti ir saistīts ar nepareizu adresi. Serveris, kas pieņem savienojumu, bet atsaka lapu, parasti neiztur resursdatora nosaukuma pārbaudi. Tie ir dažādi defekti ar dažādiem labojumiem, un pareizas konfigurācijas izvēle ir atkarīga no tā, kam jāsasniedz darbvieta un kā viņš tur nokļūst.

Atbildi nosaka trīs jautājumi: kas savienojas, kādu adresi viņš var sasniegt un vai viņam jādarbojas tiešajai pārlādei.

Sāciet ar ligzdu, nevis ar konfigurācijas failu

Izlasiet, kam darbojošais process patiešām ir piesaistīts tajā pašā tīkla kontekstā, kas to palaida, jo konteiners vai nosaukumu telpa var piederēt ligzdai, kuru resursdatora čaula neredz. Klausīšanās kolonna atbild uz pirmo jautājumu: tikai vietējais ceļš, viena konkrēta saskarne vai visas saskarnes.

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

Atgriezeniskās cilpas adrese ir droša noklusējuma vērtība un bezjēdzīga attālinātam klientam. Aizstājējzīmes saistīšana ir ērta un atver portu katrā saskarnē, kurai ir maršruts, kas ir plašāk, nekā vairums cilvēku paredz mašīnā, kas pārvadā arī tuneli. Konkrēta adrese ir vidējais variants, un tā darbojas tikai tad, ja saskarnei šī adrese pieder ligzdas izveides brīdī. Atšķirība ir svarīga, jo divas no šīm trim saistīšanām pārlūkā izskatās vienādi un uzvedas pilnīgi citādi, tiklīdz pastāv otra saskarne.

Pielāgojieties šim novērojumam, pirms aiztiekat maršrutus vai ugunsmūra noteikumus. Ja process klausās nepareizajā adresē, neviena politikas maršrutēšana klientu tur nenovedīs.

Izvēlieties saistīšanas adresi pēc tā, kam tā jāsasniedz

Ja lapa ir vajadzīga tikai jums šajā mašīnā, saglabājiet atgriezeniskās cilpas saistīšanu un apstājieties. Ja tā vajadzīga vienam kolēģim tajā pašā tunelī, piesaistiet tuneļa saskarnes adresi un ļaujiet ugunsmūrim atļaut tikai šo avotu. Izstrādes servera publicēšana ārpus cilvēkiem, kuri to aktīvi testē ir ieradums, kas galu galā pakļauj darbvietu internetam.

Ja pārlūkam konteinera iekšienē jāsasniedz serveris, saistīšanas adresei jābūt tādai, uz kuru konteinera tīkls var maršrutēt, un tas bieži nav adrese, ko resursdators atrisina sev. Izlemiet gadījumu pirms konfigurācijas rediģēšanas, jo trīs gadījumi dod trīs dažādas vērtības un tikai viena ir pareiza. Minēšana šeit iztērē vairāk laika nekā jebkura cita iestatīšanas daļa.

Pēc tam iestatiet adresi tādā formā, kuru jūsu palaidējs patiešām nolasa. Konfigurācijas fails un skripts, kas programmatiski būvē serveri, nepatērē vienas un tās pašas opcijas:

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

Adrese šajā fragmentā ir ilustratīva un apzīmē VPN adresi, kas pieder resursdatoram. Ja projekts būvē serveri ar new WebpackDevServer(options, compiler) nododiet opcijas caur konstruktora argumentu, jo atsevišķais devServer rekvizīts webpack konfigurācijā šajā ceļā netiek aplūkots. Šī atšķirība starp konfigurācijas failu un Node API noķer tos, kas fragmentu iekopē projektā, kas to nekad nelasa. dev-server dokumentācija atdala divus palaišanas stilus un ir atsauce, ar ko salīdzināt izmantoto versiju.

Saskaņojiet resursdatora nosaukuma pārbaudi ar nosaukumiem, ko apstiprināt

Resursdatora nosaukuma pārbaude pastāv, lai neļautu lapai, kas pasniegta no uzbrucēja kontrolēta nosaukuma, pārlūkā runāt ar jūsu izstrādes serveri. Tās atslēgšana ar allowedHosts: "all" noņem šo aizsardzību, un ērtība mašīnā, kas sasniedz iekšējos pakalpojumus, reti ir tā vērta. Pārbaudi ir lēti pareizi apmierināt, kad zināt, kādus nosaukumus pārlūks sūtīs.

Uzskaitiet precīzos nosaukumus, ko izmantosiet, tostarp privāto nosaukumu, kas atrisinās uz tuneļa adresi. Ja klients atrisina nosaukumu uz citu adresi nekā to, kurai piesaistījāties, jums ir nosaukumu atrisināšanas problēma, nevis servera konfigurācijas problēma, un nosaukuma pievienošana atļauto sarakstam to neizlabos. Apstipriniet atrisinājumu no klienta, nevis no servera.

Turiet trīs vadīklas atsevišķi galvā: saistīšanas adrese nosaka, kuras saskarnes pieņem savienojumu, atļauto saraksts nosaka, kuras Host galvenes tiek pieņemtas, un autentifikācija nosaka, kam ir atļauts iekšā. Tikai trešā ir piekļuves kontrole, un izstrādes serverim parasti tās nav. Arī tuneļa adrese nav autentifikācijas mehānisms, jo ikviens, kas tur var maršrutēt, jau ir tajā robežā, uz kuru jūs paļāvāties.

Pārbaudiet lapu un tiešās pārlādes ligzdu kopā

Ielādējiet jaunu pieprasījumu no paredzētā klienta ar konfigurēto shēmu un lasiet rezultātu, nevis kešatmiņu. HTTPS gadījumā saglabājiet gaidāmo resursdatora nosaukumu un sertifikāta validāciju, jo pārlūka brīdinājums nav veiksmīgs pieņemšanas tests. Lapa, kas tiek attēlota, kamēr tiešā pārlāde klusi cieš neveiksmi, šeit ir visbiežākā daļējā veiksme, un to ir viegli palaist garām ātrā pārbaudē.

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

Pēc tam atveriet pārlūka tīkla diagnostiku un vērojiet WebSocket savienojumu. Lapa var ielādēties caur vienu resursdatora nosaukumu, portu un shēmu, kamēr pārlādes ligzda izmanto citu, tāpēc abi ir jāpārbauda atsevišķi. Konfigurējiet dokumentēto klienta URL tikai tad, kad izvietotais ceļš patiešām prasa citu vērtību, un dodiet priekšroku ceļa labošanai, nevis apiešanas mācīšanai klientam.

Pierakstiet klausītāja adresi, pieņemto nosaukumu, atļauto avotu un abus rezultātus projekta piezīmēs. Šis ieraksts pārdzīvos nākamo cilvēku, kurš palaidīs darbvietu un brīnīsies, kāpēc lapa ielādējas, bet nekad neatjaunojas.

Saistītie raksti