ชื่อ DNS ส่วนตัวหรือแค่ IP? ตัดสินใจก่อนแชร์

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

เงื่อนไขข้อหนึ่ง: ลูกค้ามีเส้นทางตัวแก้ไขชื่อแบบใด

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

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

ตัวแก้ไขชื่อสาธารณะจะไม่เรียนรู้โซนส่วนตัวเพียงเพราะแล็ปท็อปเชื่อมต่อกับ VPN

ส่วนต่อท้ายสมควรได้รับความสนใจเท่ากัน ใช้โดเมนย่อยของโดเมนที่องค์กรควบคุม เพื่อให้ความเป็นเจ้าของและการวางแผนใบรับรองชัดเจน หลีกเลี่ยง .local: ข้อกำหนด multicast DNS ผูกส่วนต่อท้ายนั้นกับการแก้ชื่อแบบ link-local และอุโมงค์ที่กำหนดเส้นทางไม่ได้จำลองพฤติกรรมนั้นให้คุณ

เงื่อนไขข้อสอง: บริการได้รับแหล่งใด

กฎการรับเข้าถูกเขียนเทียบกับที่อยู่ คำถามที่มีประโยชน์จึงเป็นว่าบริการเห็นที่อยู่ใดหลังการกำหนดเส้นทางและการแปล สำหรับบริการตัวอย่างที่ 10.20.30.40 ลูกค้าสำนักงานมาจาก 10.20.30.0/24 และลูกค้าระยะไกลมาจากกลุ่มแยกเช่น 10.99.0.0/24

หากเกตเวย์แปลกลุ่มระยะไกล บริการจะเห็นตัวแปล และกฎที่เขียนสำหรับ 10.99.0.0/24 จะไม่ตรงกัน

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

เงื่อนไขข้อสาม: ชื่อผูกกับบริการหรือผูกกับโฮสต์

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

สำหรับบริการภายในเดียว บันทึกโดยตรงมักเหมาะสมและคิดตามได้ง่ายกว่า

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

ทดสอบการตัดสินใจสองข้อแยกกัน

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

curl -sv --max-time 5 https://files.corp.example/health

จากนั้นทดสอบแหล่งที่ถูกห้ามหนึ่งครั้ง และบันทึกผล

เก็บบันทึกสองรายการแยกกันในเอกสารของคุณ คือชื่อและโซนของมัน แหล่งที่รับเข้าและเจ้าของกฎ เมื่ออย่างหนึ่งเปลี่ยน อีกอย่างไม่จำเป็นต้องเปลี่ยน

การตัดสินใจมักผิดพลาดตรงไหน

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

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

เขียนทั้งสองอย่างก่อนบริการเริ่มใช้งาน เพราะการเปลี่ยนแปลงครั้งต่อไปจะคิดตามได้ง่ายขึ้น บันทึกนั้นสั้น หนึ่งบรรทัดสำหรับชื่อและโซนของมัน หนึ่งบรรทัดสำหรับแหล่งที่รับเข้าและเจ้าของกฎ