VPN ไคลเอนต์บนเว็บเซิร์ฟเวอร์ของคุณทำให้การตอบกลับเสียหรือไม่?

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

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

อาการ: ตอบกลับภายในแต่ไม่ตอบจากภายนอก

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

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

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

ตัวเลือกแหล่งที่มาจับคู่อะไรจริงๆ

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

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

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

ตรวจสอบเส้นทางขากลับและทราฟฟิกที่คุณไม่ได้ตั้งใจ

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

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

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

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

ตัดสินว่าข้อยกเว้นแคบได้แค่ไหน

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

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

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