Cum să servești un server de dezvoltare webpack pe o adresă VPN

Un server de dezvoltare care răspunde pe laptop și nicăieri altundeva este de obicei legat de adresa greșită. Un server care acceptă conexiunea dar refuză pagina eșuează de obicei la o verificare a numelui de gazdă. Sunt defecte diferite cu remedieri diferite, iar alegerea configurației corecte depinde de cine trebuie să ajungă în spațiul de lucru și cum ajunge.

Trei întrebări decid răspunsul: cine se conectează, ce adresă poate atinge și dacă reîncărcarea live trebuie să funcționeze pentru el.

Începeți cu socketul, nu cu fișierul de configurare

Citiți la ce este de fapt legat procesul care rulează, în același context de rețea care l-a pornit, pentru că un container sau un spațiu de nume poate deține un socket pe care shellul gazdei nu îl vede. Coloana de ascultare răspunde la prima întrebare: doar cale locală, o interfață anume sau toate interfețele.

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

O adresă de buclă locală este valoarea implicită sigură și inutilă pentru un client la distanță. O legare cu caracter universal este comodă și expune portul pe fiecare interfață care are o rută, ceea ce este mai larg decât intenționează majoritatea oamenilor pe o mașină care poartă și un tunel. O adresă anume este opțiunea de mijloc și funcționează doar dacă interfața deține acea adresă în momentul creării socketului. Distincția contează pentru că două dintre aceste trei legări arată identic în browser și se comportă complet diferit de îndată ce există o a doua interfață.

Aliniați-vă la această observație înainte de a atinge rute sau reguli de firewall. Dacă procesul ascultă pe adresa greșită, nicio rutare bazată pe politici nu va aduce clientul acolo.

Alegeți adresa de legare în funcție de cine trebuie să o atingă

Dacă doar dumneavoastră pe această mașină aveți nevoie de pagină, păstrați legarea de buclă locală și opriți-vă. Dacă un coleg de pe același tunel are nevoie de ea, legați adresa interfeței tunelului și lăsați firewallul să permită doar acea sursă. Publicarea unui server de dezvoltare dincolo de oamenii care îl testează activ este un obicei care ajunge în cele din urmă să expună spațiul de lucru internetului.

Dacă un browser dintr-un container trebuie să ajungă la server, adresa de legare trebuie să fie una către care rețeaua containerului poate ruta, iar aceea nu este adesea adresa pe care gazda o rezolvă pentru sine. Decideți cazul înainte de a edita configurația, pentru că cele trei cazuri produc trei valori diferite și doar una este corectă. Ghicitul aici pierde mai mult timp decât orice altă parte a instalării.

Apoi setați adresa în forma pe care lansatorul dumneavoastră o citește cu adevărat. Un fișier de configurare și un script care construiește serverul programatic nu consumă aceleași opțiuni:

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

Adresa din acel fragment este ilustrativă și reprezintă adresa VPN pe care o deține gazda. Dacă proiectul construiește serverul cu new WebpackDevServer(options, compiler) transmiteți opțiunile prin argumentul constructorului în schimb, pentru că proprietatea separată devServer din configurația webpack nu este consultată pe acea cale. Această diferență dintre fișierul de configurare și API-ul Node prinde oamenii care copiază un fragment într-un proiect care nu îl citește niciodată. Documentația dev-server separă cele două stiluri de lansare și este referința cu care trebuie comparată versiunea utilizată.

Potriviți verificarea numelui de gazdă cu numele pe care le aprobați

Verificarea numelui de gazdă există pentru a împiedica o pagină servită de la un nume controlat de un atacator să vorbească cu serverul dumneavoastră de dezvoltare prin browser. Dezactivarea ei cu allowedHosts: "all" elimină acea protecție, iar confortul merită rareori pe o mașină care poate atinge servicii interne. Verificarea este ieftin de satisfăcut corect odată ce știți ce nume va trimite browserul.

Enumerați numele exacte pe care le veți folosi, inclusiv numele privat care se rezolvă la adresa tunelului. Dacă clientul rezolvă un nume la o altă adresă decât cea la care ați legat, aveți o problemă de rezolvare a numelor și nu una de configurare a serverului, iar adăugarea numelui în lista de permise nu o va remedia. Confirmați rezolvarea din client, nu din server.

Țineți cele trei controale separate în minte: adresa de legare decide ce interfețe acceptă conexiunea, lista de permise decide ce antete Host sunt acceptate, iar autentificarea decide cine este lăsat să intre. Doar al treilea este control de acces, iar un server de dezvoltare de obicei nu are niciunul. Nici o adresă de tunel nu este un mecanism de autentificare, pentru că oricine poate ruta către ea este deja în interiorul limitei pe care vă bazat.

Verificați pagina și socketul de reîncărcare live împreună

Încărcați o cerere proaspătă de la clientul dorit cu schema configurată și citiți rezultatul, nu cache-ul. Pentru HTTPS, păstrați numele de gazdă așteptat și validarea certificatului, pentru că un avertisment de browser nu este un test de acceptare reușit. O pagină care se afișează în timp ce reîncărcarea live eșuează în tăcere este succesul parțial cel mai frecvent aici și este ușor de ratat într-o verificare rapidă.

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

Apoi deschideți diagnosticele de rețea ale browserului și urmăriți conexiunea WebSocket. O pagină se poate încărca printr-un nume de gazdă, port și schemă, în timp ce socketul de reîncărcare îl folosește pe altul, de aceea cele două trebuie verificate separat. Configurați URL-ul de client documentat doar când calea implementată are într-adevăr nevoie de o valoare diferită și preferați să corectați calea în loc să învățați clientul o soluție ocolitoare.

Notați adresa de ascultare, numele acceptat, sursa permisă și ambele rezultate în notele proiectului. Acea înregistrare supraviețuiește următoarei persoane care pornește spațiul de lucru și se întreabă de ce pagina se încarcă dar nu se actualizează niciodată.