มีหลายบริการที่บ้าน อยากเปิดผ่านชื่อเว็บแทนจำพอร์ต

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

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

ลองเริ่มจากเส้นทางของคำขอหนึ่งครั้งก่อน แล้วค่อยเพิ่มชื่อกับ HTTPS จะช่วยให้เวลาเปิดไม่ขึ้นเรารู้ว่าควรไล่จากส่วนใด แทนการแก้ทั้ง DNS ใบรับรอง และแอปพร้อมกัน

ชื่อต้องพาไปถึงจุดรับคำขอก่อน

DNS ทำหน้าที่แปลงชื่อให้ไปยังปลายทางตามการตั้งค่า ส่วน reverse proxy ที่ปลายทางนั้นดูข้อมูลคำขอแล้วเลือกบริการต่อให้ จึงควรแยกว่าตั้งชื่อให้ชี้ถูกแล้วหรือยัง กับ proxy ส่งต่อถูก service หรือไม่

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

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

ชื่อที่เลือกควรอยู่ในขอบเขตที่เราดูแลและเหมาะกับวิธีออกใบรับรอง ไม่สมมติว่าตั้งชื่ออะไรก็ขอใบรับรองสาธารณะได้ หากใช้ชื่อภายในกับ CA ภายใน ก็ต้องมีวิธีให้ client เชื่อถืออย่างถูกต้องตามการตั้งค่านั้นด้วย

ให้ proxy มองเห็นบริการในพื้นที่ของมัน

ถ้า Caddy รันอยู่ใน container คำว่า localhost ของ Caddy ก็ไม่ได้หมายถึง host หรือ container แอปทุกตัว ควรกำหนด upstream ที่เข้าถึงได้จากสภาพเครือข่ายที่ proxy อยู่ เช่น ชื่อ service บน network ร่วมตามที่วางไว้

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

dashboard.example.com {
    reverse_proxy dashboard:3000
}

files.example.com {
    reverse_proxy files:8080
}

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

หากเลือกแยกตาม path แทนชื่อย่อย ก็ควรดูว่าแอปรองรับ base path และการสร้างลิงก์อย่างไร ไม่ใช่ทุกแอปจะย้ายไปอยู่ใต้ path ใหม่ได้โดย proxy ตัดชื่อส่วนหน้าอย่างเดียวแล้วทุกอย่างยังตรง

HTTPS อัตโนมัติก็มีเงื่อนไขให้ผ่าน

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

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

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

ใบรับรองไม่ได้เลือกคนที่มีสิทธิ์ใช้แอป

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

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

header ที่บอกแหล่งคำขอก็ต้องดูว่าแอปเชื่อข้อมูลจาก proxy ที่กำหนดไว้จริงหรือไม่ โดยเฉพาะเมื่อมี proxy หลายชั้น ไม่ให้ข้อมูลที่ client ส่งเองกลายเป็นตัวตัดสินสิทธิ์เพียงเพราะชื่อ header ดูเหมือนมาจากระบบภายใน

เวลาเปิดไม่ขึ้น ไล่ทีละช่วง

เริ่มจากตรวจว่าชื่อพาไปปลายทางใด จากนั้นดูว่าต่อถึง proxy และผ่าน TLS ได้หรือไม่ แล้วจึงตรวจ upstream กับ log ของแอป การเจอข้อผิดพลาดคนละจุดมีความหมายต่างกัน จึงไม่ควรเริ่มล้างใบรับรองทุกครั้งที่ backend ไม่ตอบ

ควรลองทั้งเปิดหน้าโดยตรง การส่งแบบฟอร์ม และฟังก์ชันที่ใช้การเชื่อมต่อยาวตามงานจริง เพราะการเห็นหน้าแรกได้ยังไม่ครอบคลุมการ redirect, cookie, WebSocket หรือการอัปโหลดที่แอปใช้ และควรตรวจทางเข้าตรงของ backend ว่ายังเป็นไปตามขอบเขตที่ตั้งใจด้วย

ให้แอปรู้ว่าคนใช้เข้ามาทางไหน

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

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

สรุป

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