ทำไม URL ของคุณต้องมีทางเข้าที่พอร์ต 80 หรือ 443 ไม่ใช่ 45000

พิมพ์ชื่อโฮสต์ในเบราว์เซอร์ แล้วสคีมากำหนดพอร์ตปลายทาง: 80 สำหรับ http, 443 สำหรับ https ไม่มีสิ่งใดในคำตอบ DNS ที่ลบล้างได้ และไม่มีกฎส่งต่อใดบนเครื่องของคุณจะสร้างผู้รับฟังที่ขอบของผู้ให้บริการได้ เมื่อผู้ให้บริการ VPN มอบพอร์ตสาธารณะสูงอย่าง 45000 ให้คุณ URL ที่ระบุพอร์ตชัดเจนจึงใช้ได้ ส่วน URL ที่สะอาดใช้ไม่ได้ ช่องว่างอยู่ที่จุดเข้า ไม่ใช่ภายในแอปพลิเคชัน

ไล่เส้นทางจากเบราว์เซอร์ถึงโพรเซสสักครั้ง แล้วตัวเลือกการเผยแพร่ทั้งสามจะไม่ดูเป็นปริศนาอีก

ดูว่าคำขอไปถึงที่ใดจริง ๆ

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

การปฏิเสธนั้นเกิดขึ้นที่ขอบ จึงเป็นเหตุให้บันทึกของแอปพลิเคชันไม่แสดงอะไรเลย การไม่มีบันทึกคือหลักฐานว่าแพ็กเก็ตหยุดที่ใด ไม่ใช่หลักฐานว่าแอปพลิเคชันเสีย

ทำไมกฎภายในเครื่องจึงแก้ขอบไม่ได้

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

DNS ก็พาพอร์ตไปไม่ได้เช่นกัน ข้อกำหนด HTTP กำหนดค่าเริ่มต้นของสคีมา และระเบียน A หรือ AAAA คืนค่าที่อยู่ ขณะที่ CNAME คืนชื่ออื่น เบราว์เซอร์ยังคงต่อพอร์ตของสคีมา ดังนั้นเฉพาะพอร์ตที่ระบุชัดเจนใน URL เท่านั้นที่เปลี่ยนปลายทาง

ทางเลือกที่หนึ่ง: คงพอร์ตที่ระบุชัดเจนไว้

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

ตรวจสอบการเปลี่ยนเส้นทางและขอบเขตคุกกี้ระหว่างที่อยู่ที่นั่น เพราะแบ็กเอนด์ที่เขียนชื่อโฮสต์ของตัวเองลงในเฮดเดอร์ Location จะทำให้การจัดวางนี้เสียไป

ทางเลือกที่สอง: ได้ทางเข้าที่พอร์ตเริ่มต้นจริง ๆ

ผู้ให้บริการและรูปแบบโฮสติ้งบางรายส่งต่อ 80 และ 443 บนที่อยู่ที่ใช้ร่วมกันหรือเฉพาะเป็นบริการที่มีเอกสารกำกับ ถามว่ามีอะไรรวมอยู่จริง ๆ แทนที่จะสันนิษฐานว่าที่อยู่ขาออกสาธารณะหมายถึงพอร์ตขาเข้าใด ๆ ที่อยู่ขาออกเฉพาะไม่ได้บอกอะไรเกี่ยวกับการส่งต่อขาเข้า

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

ทางเลือกที่สาม: วางฟรอนต์เอนด์ไว้ข้างหน้า

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

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

คงต้นกำเนิดเดียว

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

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