WireGuard แฮนด์เชกทำงาน แต่บริการไม่ทำงาน

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

หยุดที่จุดแรกที่ไม่เป็นจริง และอย่าเพิ่มกฎให้จุดอื่น

แฮนด์เชกพิสูจน์เพียงอุโมงค์

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

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

อ่านตัวรอรับและเส้นทาง

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

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

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

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

ใช้กฎสำหรับขาเข้าภายในเครื่อง ไม่ใช่การส่งต่อ

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

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

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

แยกความล้มเหลวด้านชื่อ ขนาด และตัวตน

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

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

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