วิธีให้บริการเซิร์ฟเวอร์พัฒนา webpack บนที่อยู่ VPN

เซิร์ฟเวอร์พัฒนาที่ตอบสนองบนแล็ปท็อปและไม่ตอบที่อื่นมักผูกกับที่อยู่ผิด เซิร์ฟเวอร์ที่รับการเชื่อมต่อแต่ปฏิเสธหน้าเว็บมักล้มเหลวในการตรวจสอบชื่อโฮสต์ สิ่งเหล่านี้เป็นข้อบกพร่องต่างกันพร้อมวิธีแก้ต่างกัน และการเลือกการกำหนดค่าที่ถูกต้องขึ้นอยู่กับว่าใครต้องเข้าถึงพื้นที่ทำงานและเข้ามาได้อย่างไร

สามคำถามเป็นตัวกำหนดคำตอบ ใครเชื่อมต่อ ที่อยู่ใดที่เขาเข้าถึงได้ และการรีโหลดสดต้องทำงานสำหรับเขาหรือไม่

เริ่มจากซ็อกเก็ต ไม่ใช่ไฟล์กำหนดค่า

อ่านว่ากระบวนการที่กำลังทำงานผูกกับอะไรจริง ๆ ภายในบริบทเครือข่ายเดียวกับที่เริ่มมัน เพราะคอนเทนเนอร์หรือเนมสเปซอาจเป็นเจ้าของซ็อกเก็ตที่เชลล์ของโฮสต์มองไม่เห็น คอลัมน์การฟังตอบคำถามแรก คือเฉพาะเส้นทางโลคอล อินเทอร์เฟซหนึ่งที่ระบุ หรือทุกอินเทอร์เฟซ

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

ที่อยู่ลูปแบ็กเป็นค่าเริ่มต้นที่ปลอดภัยและไร้ประโยชน์สำหรับไคลเอนต์ระยะไกล การผูกแบบไวลด์การ์ดนั้นสะดวกและเปิดพอร์ตบนทุกอินเทอร์เฟซที่มีเส้นทาง ซึ่งกว้างกว่าที่คนส่วนใหญ่ตั้งใจบนเครื่องที่พกอุโมงค์ด้วย ที่อยู่เฉพาะคือตัวเลือกกลาง และจะทำงานได้ก็ต่อเมื่ออินเทอร์เฟซเป็นเจ้าของที่อยู่นั้นในขณะที่สร้างซ็อกเก็ต ความแตกต่างนี้สำคัญเพราะการผูกสองในสามแบบดูเหมือนกันในเบราว์เซอร์และทำงานต่างกันโดยสิ้นเชิงเมื่อมีอินเทอร์เฟซที่สอง

ปรับให้เข้ากับข้อสังเกตนั้นก่อนแตะเส้นทางหรือกฎไฟร์วอลล์ หากกระบวนการฟังอยู่บนที่อยู่ผิด ก็ไม่มีเส้นทางเชิงนโยบายใดทำให้ไคลเอนต์ไปถึงได้

เลือกที่อยู่ผูกตามว่าใครต้องเข้าถึง

หากมีเพียงคุณบนเครื่องนี้ที่ต้องการหน้าเว็บ ให้เก็บการผูกลูปแบ็กไว้แล้วหยุด หากเพื่อนร่วมงานหนึ่งคนบนอุโมงค์เดียวกันต้องการ ให้ผูกที่อยู่ของอินเทอร์เฟซอุโมงค์และให้ไฟร์วอลล์อนุญาตเฉพาะแหล่งนั้นการเผยแพร่เซิร์ฟเวอร์พัฒนาเกินกว่าคนที่กำลังทดสอบมันอยู่จริง เป็นนิสัยที่ท้ายที่สุดจะเปิดเผยพื้นที่ทำงานสู่อินเทอร์เน็ต

หากเบราว์เซอร์ภายในคอนเทนเนอร์ต้องเข้าถึงเซิร์ฟเวอร์ ที่อยู่ผูกต้องเป็นที่อยู่ที่เครือข่ายของคอนเทนเนอร์กำหนดเส้นทางไปได้ และนั่นมักไม่ใช่ที่อยู่ที่โฮสต์แปลงสำหรับตัวเอง ตัดสินใจกรณีนี้ก่อนแก้ไขการกำหนดค่า เพราะสามกรณีให้ค่าที่แตกต่างกันสามค่าและมีเพียงค่าเดียวที่ถูก การเดาที่นี่เสียเวลามากกว่าส่วนอื่นของการตั้งค่า

จากนั้นตั้งค่าที่อยู่ในรูปแบบที่ตัวเปิดของคุณอ่านจริง ไฟล์กำหนดค่าและสคริปต์ที่สร้างเซิร์ฟเวอร์โดยโปรแกรมไม่ได้ใช้ตัวเลือกเดียวกัน:

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 ของไคลเอนต์ตามเอกสารเฉพาะเมื่อเส้นทางที่ติดตั้งต้องการค่าอื่นจริง ๆ และเลือกแก้ไขเส้นทางมากกว่าสอนวิธีเลี่ยงให้ไคลเอนต์

บันทึกที่อยู่ผู้รับฟัง ชื่อที่ยอมรับ แหล่งที่อนุญาต และผลลัพธ์ทั้งสองลงในบันทึกของโปรเจกต์ บันทึกนั้นจะอยู่ต่อให้คนถัดไปที่เริ่มพื้นที่ทำงานและสงสัยว่าทำไมหน้าเว็บโหลดได้แต่ไม่เคยรีเฟรช