IP VPN แบบเฉพาะไม่ทำให้เว็บไซต์ของคุณเผยแพร่
ที่อยู่ขาออกแบบเฉพาะไม่ได้บอกอะไรเกี่ยวกับการส่งเข้าเลย ตรวจสอบสัญญาการส่งต่อ ทำฝั่งต้นทางให้เสร็จ แล้วจึงเผยแพร่พอร์ตสูง
การซื้อ IP แบบเฉพาะจากผู้ให้บริการ VPN ให้ความรู้สึกเหมือนซื้อประตูหน้า ที่อยู่คงที่ อุโมงค์ทำงาน แต่เว็บไซต์ก็ยังโหลดไม่ได้สำหรับใครก็ตามที่อยู่ข้างนอก สิ่งที่คุณซื้อคือ การกำหนดที่อยู่ ไม่ใช่กฎการส่งต่อขาเข้า. ทั้งสองอย่างขายในร้านเดียวกันและตั้งค่าในตำแหน่งที่ต่างกันโดยสิ้นเชิง
ที่อยู่คือการกำหนด ไม่ใช่กฎการส่งต่อ
บันทึกที่อยู่สาธารณะขาเข้าหรือชื่อโฮสต์ การขนส่งที่อนุญาต พอร์ตภายนอกที่กำหนด และปลายทางฝั่งไคลเอนต์ที่ผู้ให้บริการส่งไปถึง จากนั้นยืนยันว่าเซิร์ฟเวอร์ โปรโตคอล และคุณสมบัติบัญชีที่คุณเลือกนั้นรองรับการส่งต่อจริง และผู้ให้บริการอนุญาตให้โฮสต์บนนั้น
คำว่าเฉพาะอธิบายการกำหนดที่อยู่ ไม่ได้หมายความว่าอนุญาตทราฟฟิกขาเข้าที่ไม่ได้ร้องขอ และส่วนเสริมต่างๆ ของผู้ให้บริการรายเดียวกันอาจมีความสามารถต่างกัน ที่อยู่แบบเฉพาะกับผลิตภัณฑ์เซิร์ฟเวอร์แบบเฉพาะเป็นสองป้ายที่คนสับสนมากที่สุด และหน้าช่วยเหลือมักระบุว่าอันไหนส่งต่อ
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
สัญญาตัวอย่างมีลักษณะเช่นนี้ ผู้ให้บริการส่ง TCP 203.0.113.60:45000 ไปยังบริการ HTTPS ของอุปกรณ์ที่เชื่อมต่อของคุณที่พอร์ต 8443 นั่นคือคำอธิบายของการแมปที่คนอื่นตั้งค่าไว้ ไม่ใช่กฎที่คุณสร้างที่ขอบของพวกเขาได้ด้วยการพิมพ์ลงในไฟร์วอลล์ของคุณเอง
ทำฝั่งต้นทางให้เสร็จ
หากเว็บแอปพลิเคชันทำงานบนไคลเอนต์ VPN เอง ก็ต้องมีตัวรับฟังที่พอร์ตที่ส่งมาและสิทธิ์อินพุตภายในเครื่องแบบจำกัดสำหรับพอร์ตนั้น หากไคลเอนต์ส่งต่อการเชื่อมต่อที่แมปไปยังโฮสต์อื่น ก็ต้องมีการแปลปลายทาง นโยบายการส่งต่อ และเส้นทางตอบกลับที่ทนต่อการไปกลับ
ออกแบบกฎการเข้าถึงโดยอิงที่อยู่ต้นทางที่เส้นทางของผู้ให้บริการนำเสนอจริง ไม่ใช่ผู้เยี่ยมชมเดิมเสมอไป และไม่ใช่เซิร์ฟเวอร์ VPN เสมอไป ซึ่งสำคัญเมื่อคุณเขียนกฎที่จะตรงกับที่อยู่ใดที่อยู่หนึ่งเท่านั้น
การแปลพอร์ตก็ไม่ได้เปลี่ยน HTTP เป็น HTTPS พอร์ตสาธารณะกับพอร์ตแอปพลิเคชันภายในเครื่องอาจต่างกันได้อย่างอิสระ แต่สคีม อัตลักษณ์ของใบรับรอง และการเปลี่ยนเส้นทางยังต้องตรงกับบริการที่ผู้คนเข้าถึงจริง หากใบรับรองระบุชื่อโฮสต์สาธารณะ ก็ให้คงชื่อนั้นไว้ในทุกช่วง หากไม่ตรงกันที่นี่จะปรากฏเป็นคำเตือนของเบราว์เซอร์ ไม่ใช่ความล้มเหลวในการกำหนดเส้นทาง ซึ่งทำให้ผู้คนไปดูบันทึกผิดที่เป็นเวลาหนึ่งชั่วโมง
เผยแพร่พอร์ตสูงอย่างตรงไปตรงมา
หากผู้เยี่ยมชมเชื่อมต่อโดยตรงและผู้ให้บริการกำหนดพอร์ตสูง ให้ URL ที่สมบูรณ์แก่พวกเขา บันทึกที่อยู่ DNS ทั่วไปไม่สามารถต่อพอร์ตให้คำขอ HTTPS ที่ใช้ 443 โดยค่าเริ่มต้นได้ และการปรับ TTL ก็ไม่เปลี่ยนสิ่งนั้น
ฟรอนต์เอนด์เว็บสามารถแก้ปัญหานี้ได้โดยรับผู้เยี่ยมชมที่พอร์ตปกติและสร้างการเชื่อมต่อของตัวเองไปยังพอร์ตต้นทางที่ส่งต่อมา อย่างไรก็ตาม พอร์ตพร็อกซีเริ่มต้นของ Cloudflare เป็นรายการที่กำหนดไว้ และพอร์ตที่กำหนดโดยพลการไม่ได้กลายเป็นพอร์ตขอบที่รองรับเพียงเพราะคุณเพิ่มบันทึก DNS ที่ผ่านพร็อกซี
การเปลี่ยนพอร์ตปลายทางของต้นทางเป็นการดำเนินการที่ต่างจากการเปลี่ยนพอร์ตของผู้เยี่ยมชม Origin Rules ของ Cloudflare เอกสารการเขียนทับพอร์ตปลายทางสำหรับการเชื่อมต่อกับแบ็กเอนด์ ซึ่งจำกัดอยู่ในกฎ สคีม และชื่อโฮสต์ที่รองรับ การเขียนทับพอร์ตไม่ใช่รีเลย์ทั่วไปสำหรับ UDP โดยพลการหรือโปรโตคอลอื่น
เมื่อฟรอนต์เอนด์สิ้นสุด TLS ให้ตรวจสอบทั้งสองช่วง คือใบรับรองจากเบราว์เซอร์ถึงฟรอนต์เอนด์ และการเชื่อมต่อจากฟรอนต์เอนด์ถึงต้นทาง ช่วง VPN ไม่ได้แทนที่การตรวจสอบทั้งสองอย่างใดเลย และการที่ที่อยู่ภายในรั่วไหลไปในการเปลี่ยนเส้นทางหรือคุกกี้เป็นสัญญาณปกติว่ามีเพียงหนึ่งในสองอย่างที่ถูกตั้งค่าโดยคำนึงถึงชื่อสาธารณะ
ทำให้การแมปยังมีชีวิต
ผู้ให้บริการบางรายกำหนดพอร์ตอื่นหลังการเชื่อมต่อใหม่ และการแมปแบบเช่าอาจต้องต่ออายุผ่านการดำเนินการฝั่งผู้ให้บริการ ติดตามกลไกที่ผู้ให้บริการของคุณจัดทำเอกสาร และอัปเดตตัวรับฟัง กฎภายในเครื่อง DNS หรือกฎของฟรอนต์เอนด์เฉพาะที่ที่สัญญาปัจจุบันกำหนด
ที่อยู่สาธารณะแบบคงที่ไม่ได้ทำให้การเช่าพอร์ตคงที่ ที่อยู่และพอร์ตที่ยังแสดงอยู่ในแดชบอร์ดไม่ใช่หลักฐานว่าเซสชันที่ทำงานอยู่เป็นเจ้าของการแมป นั่นคือเหตุผลที่การทดสอบคือคำขอใหม่จากภายนอก ไม่ใช่ภาพหน้าจอ
จากนั้นทำซ้ำกรณีที่คุณคาดว่าจะเกิดขึ้น คือการเชื่อมต่อใหม่ปกติและการสูญเสีย VPN หากการสูญเสียควรทำให้ต้นทางเข้าถึงไม่ได้ อย่าให้ตัวอัปเดตเผยแพร่เส้นทาง ISP โดยตรงซ้ำอย่างเงียบๆ ในเบื้องหลัง และหากสัญญาการส่งต่อไม่สามารถตอบสนองข้อกำหนดด้านเสถียรภาพของไซต์ได้ ให้เลือกวิธีการเผยแพร่แบบอื่นแทนการซื้อป้ายที่อยู่อีกอันแล้วหวังว่ามันจะทำตัวเหมือนเซิร์ฟเวอร์