สาธารณะ ส่วนตัว คงที่ และเฉพาะ เป็นคุณสมบัติของที่อยู่ที่เป็นอิสระต่อกัน สร้างแผนผังการปรับใช้ที่ครอบคลุมการกำหนดเส้นทาง ไฟร์วอลล์ DNS ไปข้างหน้า DNS ย้อนกลับ และ TLS ด้วย และตรวจสอบแต่ละค่าตั้งกับฝ่ายที่ควบคุมมัน
คุณสมบัติของที่อยู่ตอบคำถามที่ต่างกัน
สาธารณะและส่วนตัวอธิบายว่าที่อยู่ถูกกำหนดเส้นทางไปที่ใด คงที่และไดนามิกอธิบายว่าการกำหนดที่อยู่มีพฤติกรรมอย่างไรเมื่อเวลาผ่านไป เฉพาะและใช้ร่วมกันอธิบายว่าที่อยู่ถูกใช้หรือจัดสรรภายในบริการอย่างไร คุณสมบัติเหล่านี้แยกจากกัน: ที่อยู่สาธารณะที่มั่นคงอาจให้บริการหลายไซต์ และที่อยู่ส่วนตัวสามารถกำหนดแบบไดนามิกภายในเครือข่ายที่ควบคุมได้
เขียนบทบาทของแต่ละที่อยู่ในการปรับใช้: จุดเข้าใช้งานสาธารณะ ฐานข้อมูลภายใน เส้นทางจัดการ หรือการเชื่อมต่อขาออก จากนั้นระบุว่าใครจัดสรรและอะไรเปลี่ยนแปลงได้ สิ่งนี้ป้องกันไม่ให้งานกำหนดค่าขึ้นอยู่กับสมมติฐาน เช่น เฉพาะหมายถึงถูกตรึงอย่างถาวร หรือสาธารณะหมายถึงบริการเข้าถึงได้ การเข้าถึงยังขึ้นอยู่กับการกำหนดเส้นทาง ไฟร์วอลล์ และตัวรับฟังของแอปพลิเคชัน
ที่อยู่ส่วนตัวยังต้องมีการกำหนดเส้นทางและการควบคุมการเข้าถึง
RFC 1918 สงวนช่วง IPv4 10.0.0.0/8, 172.16.0.0/12 และ 192.168.0.0/16 สำหรับเครือข่ายส่วนตัว ที่อยู่ของช่วงเหล่านี้ไม่ใช่ปลายทางสาธารณะที่ไม่ซ้ำกันทั่วโลก เครือข่ายอาจแปลงที่อยู่ส่วนตัวสำหรับการเชื่อมต่อขาออกหรือเชื่อมต่อเครือข่ายส่วนตัวผ่านเส้นทางที่ชัดเจน บริการขาเข้าที่อยู่หลังการแปลงต้องมีวิธีการเผยแพร่ที่ตั้งใจไว้ การเปลี่ยนระเบียน DNS เพียงอย่างเดียวไม่ได้สร้างเส้นทางนั้น
IPv6 มีประเภทและขอบเขตที่อยู่ของตัวเอง รวมถึงที่อยู่ลิงก์โลคัลและที่อยู่ยูนิแคสต์ที่กำหนดเส้นทางได้ทั่วโลก ตรวจสอบแยกต่างหาก แทนที่จะสมมติว่ากฎไฟร์วอลล์หรือการแปลง IPv4 ครอบคลุม IPv6 ที่อยู่ส่วนตัวไม่ใช่กลไกยืนยันตัวตน และที่อยู่ IPv6 สาธารณะไม่ใช่เหตุผลให้เปิดเผยทุกบริการ ทดสอบการเข้าถึงจากแต่ละเครือข่ายที่เกี่ยวข้องและจำกัดการดูแลที่ขอบเขตที่เหมาะสม
ชื่อที่มั่นคงและที่อยู่ที่มั่นคงเกี่ยวข้องกัน
DHCP จัดสรรการกำหนดค่าที่อยู่ผ่านโปรโตคอลและสามารถใช้สัญญาเช่าได้ ที่อยู่ที่กำหนดแบบไดนามิกอาจไม่เปลี่ยนแปลงเป็นเวลาหนึ่ง ซึ่งไม่ได้ทำให้ความถาวรของมันเป็นข้อรับประกันตามสัญญา เมื่อแอปพลิเคชันขึ้นอยู่กับที่อยู่ที่มั่นคง โปรดตรวจสอบนโยบายการจัดสรรและการเปลี่ยนแปลงของผู้ให้บริการ แทนที่จะอนุมานจากการเชื่อมต่อเมื่อวาน
DNS แบบไดนามิกสามารถอัปเดตชื่อหลังที่อยู่เปลี่ยนได้ แต่ไคลเอนต์อาจยังแคชคำตอบเดิมไว้ นอกจากนี้ยังเอาชนะตัวรับฟังที่เข้าถึงไม่ได้ เส้นทางขาเข้าที่ขาดหาย หรือการแปลงที่อยู่ระดับผู้ให้บริการไม่ได้ ใช้มันเมื่อเครือข่ายอนุญาตการเชื่อมต่อและแอปพลิเคชันทนความล่าช้าในการอัปเดตได้ สำหรับการปรับใช้แบบโฮสต์ จัดทำเอกสารวงจรชีวิตของที่อยู่ที่ตั้งใจไว้ก่อนสร้างรายการอนุญาตหรือการเชื่อมต่อภายนอกโดยอิงจากมัน
| คุณสมบัติ | สิ่งที่ต้องยืนยัน | สมมติฐานผิดพลาดที่พบบ่อย |
|---|---|---|
| สาธารณะหรือส่วนตัว | ขอบเขตการกำหนดเส้นทางและเส้นทางการเข้าถึง | ที่อยู่เพียงอย่างเดียวทำให้บริการเข้าถึงได้ |
| คงที่หรือไดนามิก | นโยบายการจัดสรรและการเปลี่ยนแปลง | สัญญาเช่าที่ไม่เปลี่ยนคือถาวร |
| เฉพาะหรือใช้ร่วมกัน | การจัดสรรและการใช้งานที่อนุญาต | ที่อยู่เฉพาะให้ตัวตนแบบไม่ระบุชื่อ |
| IPv4 หรือ IPv6 | ทั้งการกำหนดเส้นทางและการกำหนดค่าไฟร์วอลล์ | ค่าตั้งของโปรโตคอลหนึ่งครอบคลุมอีกโปรโตคอล |
DNS ไปข้างหน้าและ DNS ย้อนกลับมีเจ้าของต่างกัน
DNS ไปข้างหน้าแมปชื่อไปยังข้อมูล เช่น ระเบียนที่อยู่ A และ AAAA DNS ย้อนกลับใช้เนมสเปซที่เกี่ยวข้องกับที่อยู่และระเบียน PTR เพื่อเชื่อมโยงที่อยู่กับชื่อ องค์กรที่ควบคุมโซน DNS ไปข้างหน้าไม่จำเป็นต้องเป็นองค์กรที่ควบคุม DNS ย้อนกลับสำหรับช่วงที่อยู่ ขอเส้นทางการกำหนดค่าที่ถูกต้องก่อนสัญญาชื่อย้อนกลับ
ตรวจสอบระเบียนผ่านตัวแก้ไขชื่อที่เหมาะสมและบันทึกผลลัพธ์ สำหรับ PTR ที่ตั้งใจจะระบุโฮสต์ ให้ตรวจสอบด้วยว่าระเบียนไปข้างหน้าที่สอดคล้องชี้ไปยังที่อยู่ที่คาดไว้หรือไม่ DNS ย้อนกลับสามารถสนับสนุนการระบุตัวตนในการดำเนินงานและการตรวจสอบระบบเมลบางอย่างได้ แต่ไม่ได้ยืนยันตัวตนแอปพลิเคชันหรือรับประกันการส่งข้อความ การส่งเมลยังต้องมีการตรวจสอบโดเมน ชื่อเสียง และการยืนยันตัวตนของตัวเอง
ไม่จำเป็นต้องมีที่อยู่เฉพาะสำหรับทุกไซต์ HTTPS
การกำหนดเส้นทางโฮสต์ HTTP และส่วนขยาย Server Name Indication ของ TLS อนุญาตให้ไคลเอนต์และเซิร์ฟเวอร์ที่รองรับเลือกไซต์หรือใบรับรองตามชื่อได้ ดังนั้นไซต์ HTTPS หลายแห่งจึงสามารถใช้ที่อยู่เดียวได้โดยไม่ต้องมีที่อยู่สาธารณะหนึ่งที่อยู่ต่อโดเมน การกำหนดค่าโฮสติ้งจริงและไคลเอนต์ที่จำเป็นเป็นตัวกำหนดว่าการจัดวางนั้นเหมาะสมหรือไม่
เลือกที่อยู่เพิ่มเติมเฉพาะเมื่อข้อกำหนดที่มีเอกสารระบุว่าต้องการ เช่น การแยกเครือข่ายที่รองรับหรือระบบภายนอกที่คาดหวังปลายทางที่แตกต่างกัน ที่อยู่ไม่ได้ให้ความคุ้มกันจากปัญหาชื่อเสียงหรือระบุตัวบุคคลที่ดำเนินบริการ แยกการตรวจสอบใบรับรอง การกำหนดเส้นทางตามชื่อโฮสต์ และการจัดสรรที่อยู่ไว้ต่างหาก ตรวจสอบใบรับรองที่ให้บริการผ่านชื่อโฮสต์ที่ผู้ใช้จะเข้าชมจริง
ใช้แผนผังการปรับใช้ก่อนเปลี่ยนระเบียน
สร้างแผนผังเล็ก ๆ ที่มีชื่อโฮสต์แต่ละรายการ ระเบียนที่อยู่ ตัวรับฟัง เส้นทางไฟร์วอลล์ และผู้รับผิดชอบ รวมการดูแลระบบ การสำรองข้อมูล และรายการอนุญาตขาออกใด ๆ ตรวจสอบว่าการกำหนดค่า SwissOctet มีตัวเลือกที่อยู่ที่คุณต้องการหรือไม่ และสอบถามเกี่ยวกับการควบคุม DNS ย้อนกลับก่อนพึ่งพามัน อย่านำเสนอตัวเลือกในแค็ตตาล็อกว่าเป็นการจัดสรรจริงที่เตรียมไว้แล้ว
ระหว่างการย้าย ให้เตรียมแอปพลิเคชันปลายทางและค่าตั้ง TLS ก่อนนำผู้ใช้ไปที่นั่น คำนึงถึงแคช DNS และรักษาเส้นทางการกู้คืนที่ใช้งานได้ ตรวจสอบการแก้ชื่อไปข้างหน้า การเข้าถึงแอปพลิเคชันจริง และชื่อย้อนกลับที่คาดไว้แยกกัน แผนผังทำให้หาความล้มเหลวได้ง่ายขึ้น เพราะระเบียนผิด พอร์ตปิด และใบรับรองไม่ตรงกันเป็นปัญหาต่างกันที่มีเจ้าของต่างกัน
รายการตรวจสอบปฏิบัติของคุณ
- จับคู่บทบาทของที่อยู่ การจัดสรร และความเป็นเจ้าของ
- ตรวจสอบ IPv4 และ IPv6 แยกกัน
- ตรวจสอบเส้นทางขาเข้าก่อนพึ่งพา DNS
- ระบุว่าใครควบคุมระเบียน PTR
- ทดสอบชื่อโฮสต์ ใบรับรอง และแอปพลิเคชันร่วมกัน
รายละเอียดที่สำคัญ
IP เฉพาะทำให้บริการไม่ระบุชื่อหรือไม่+
ไม่ มันอธิบายการจัดสรรหรือการจัดวางการใช้งาน ไม่ใช่การรับประกันตัวตนหรือความเป็นส่วนตัว บัญชี ทราฟฟิก และข้อมูลแอปพลิเคชันมีนัยที่แยกจากกัน
ฉันตั้งระเบียน PTR จากแผง DNS ของโดเมนได้หรือไม่+
ได้เฉพาะเมื่อมันควบคุมโซนย้อนกลับที่เกี่ยวข้องด้วย โดยทั่วไปผู้ให้บริการที่อยู่ควบคุมโซนนั้นหรือมีกระบวนการขอแยกต่างหาก
แต่ละโดเมน HTTPS ต้องมีที่อยู่ของตัวเองหรือไม่+
ไม่จำเป็นเสมอไป ไคลเอนต์และเซิร์ฟเวอร์ที่รองรับสามารถใช้การกำหนดเส้นทางตามชื่อและ TLS SNI ได้ ตรวจสอบข้อกำหนดจริงของโฮสติ้งและไคลเอนต์
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- RFC 1918: การจัดสรรที่อยู่สำหรับอินเทอร์เน็ตส่วนตัว www.rfc-editor.org
- RFC 2131: Dynamic Host Configuration Protocol www.rfc-editor.org
- RFC 1035: การนำไปใช้และข้อกำหนดของ DNS www.rfc-editor.org
- RFC 4291: สถาปัตยกรรมการกำหนดที่อยู่ IPv6 www.rfc-editor.org
- RFC 6066: ส่วนขยาย TLS รวมถึง Server Name Indication www.rfc-editor.org
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก