คิวรีฐานข้อมูลค้างเหนือ IPsec: การจัดลำดับ UDP ใหม่หรือ TCP?
คิวรีที่ค้างหลังแฮนด์เชกที่สะอาดชี้ไปภายในเส้นทางของอุโมงค์ สามเงื่อนไขตัดสินว่าจะซ่อมเส้นทางหรือถอยกลับไปใช้ TCP บน 443
คิวรีที่ค้างหลังแฮนด์เชก TCP ไม่ใช่ปัญหาเส้นทาง หาเส้นทางผิดทำให้แฮนด์เชกล้มเหลว เซสชันที่สร้างขึ้นแล้วเงียบไปจึงชี้ไปภายในเส้นทาง คือการตรวจสอบ MTU หรือวิธีที่แพ็กเก็ต UDP ของอุโมงค์มาถึง การตัดสินใจตรงหน้าคือจะซ่อมเส้นทางนั้นหรือย้ายอุโมงค์ไปใช้ TCP สามเงื่อนไขตัดสินเรื่องนี้ และไม่มีข้อใดเกี่ยวกับฐานข้อมูล
จำแนกการค้างก่อนตำหนิอุโมงค์
ผลลัพธ์สี่แบบดูเหมือนกันสำหรับผู้ใช้ แต่มีความหมายต่างกันโดยสิ้นเชิงสำหรับวิศวกร
| What the client sees | What it rules out |
|---|---|
| Connection refused | Nothing is listening on the address and port the client reached |
| Timeout before the handshake | A filter, a missing route, or the wrong address |
| Handshake completes, query hangs | The session exists, so look at inspection, MTU and packet order |
| Stalls that recover on retry | Often reordering, or a state table entry expiring |
มีเพียงสองแถวสุดท้ายที่สมควรใช้เวลากับอุโมงค์ การเชื่อมต่อที่ถูกปฏิเสธผ่าน VPN มักเป็นฐานข้อมูลที่รับฟังเฉพาะบน loopback ซึ่งเป็นปัญหาของตัวรับฟัง และการหมดเวลาก่อนแฮนด์เชกคือตัวกรองหรือเส้นทาง ทั้งสองไม่ดีขึ้นจากการเปลี่ยนการห่อหุ้ม
เขียนการจำแนกลงในตั๋วก่อน เป็นขั้นตอนที่ถูกที่สุดและตัดพื้นที่การค้นหาออกไปมาก
สามเงื่อนไขที่ตัดสินระหว่าง UDP กับ TCP
ทราฟฟิก IPsec ที่ถูกห่อหุ้มเดินบน UDP และ UDP ให้อิสระกับเส้นทางในการจัดลำดับใหม่และทิ้งโดยไม่บอกใคร เมื่อการจัดลำดับใหม่ดันแพ็กเก็ตออกนอกหน้าต่างป้องกันการเล่นซ้ำของอุโมงค์ แพ็กเก็ตเหล่านั้นจะถูกทิ้งอย่างเงียบ ๆ และเซสชัน TCP ชั้นในก็เพียงรออยู่ นั่นคือกลไกเบื้องหลังแฮนด์เชกที่สำเร็จและคิวรีที่ไม่เคยกลับมา
การซ่อมเส้นทางหรือถอยกลับไปใช้ TCP ขึ้นอยู่กับสามอย่าง หนึ่ง มีการสูญหายของแพ็กเก็ตจริงบนเส้นทางหรือเพียงการจัดลำดับใหม่ สอง เปลี่ยนตำแหน่งที่การตรวจสอบเกิดขึ้นได้หรือไม่ หรือยกเว้นอุโมงค์นี้จากองค์ประกอบที่จัดลำดับใหม่ สาม ภาระงานไวต่อรูปแบบการค้างหรือไม่ เช่นเซสชันมัลติเพล็กซ์จำนวนมากที่ใช้ลิงก์เดียวร่วมกัน
หากคำตอบแรกคือการสูญหายและคำตอบที่สองคือไม่TCP บน 443 คือทางเลือกที่ใช้ได้จริงหากคำตอบที่สองคือใช่ ให้ซ่อมเส้นทางและคง UDP ไว้
อ่านบันทึกของไฟร์วอลล์ ไม่ใช่ข้อผิดพลาดของแอปพลิเคชัน
แอปพลิเคชันรายงานการหมดเวลา ซึ่งไม่ได้บอกอะไรเกี่ยวกับสาเหตุ บันทึกของไฟร์วอลล์เองคือที่ที่การทิ้งหรือการบล็อกปรากฏ ดังนั้นกรองตามที่อยู่ของฐานข้อมูลและแอปพลิเคชัน และมองหาการทิ้งเช่นเดียวกับการยอมรับเบลดป้องกันภัยคุกคามสามารถทิ้งแพ็กเก็ตได้โดยไม่สร้างข้อผิดพลาดในระดับแอปพลิเคชันและนั่นคือรูปร่างที่แท้จริงของคิวรีที่ค้าง ความเงียบในบันทึกก็เป็นข้อมูลเช่นกัน มันชี้ไปที่สิ่งที่ไม่ได้บันทึก เช่นการจัดลำดับใหม่
ตรวจสอบคลัสเตอร์ด้วย คลัสเตอร์ที่กำหนดค่าไม่ถูกต้องอาจเก็บเซสชันไว้ในตารางสถานะบนสมาชิกตัวหนึ่งในขณะที่แพ็กเก็ตไปตามเส้นทางของสมาชิกอีกตัว ทำให้คำตอบไปถึงที่ที่ไม่มีสถานะ การค้างแบบนั้นดูเหมือนสุ่มและไม่สัมพันธ์กับภาระ
เปรียบเทียบทั้งสองปลายก่อนเปลี่ยนอะไร และเปรียบเทียบลำดับการมาถึงไม่ใช่จำนวนแพ็กเก็ต
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapTCP บน 443 ทำให้คุณเสียอะไรจริง ๆ
การย้ายอุโมงค์ไปใช้ TCP ขจัดอาการของการจัดลำดับใหม่ เพราะกล่องตรงกลางเห็นสตรีมที่มีลำดับแล้ว แต่ก็สร้าง TCP ซ้อน TCP การเชื่อมต่อชั้นนอกส่งซ้ำสิ่งที่ชั้นในส่งซ้ำไปแล้ว และการสูญหายเพียงครั้งเดียวอาจหยุดทุกเซสชันมัลติเพล็กซ์พร้อมกัน บนเส้นทางที่สะอาดมองไม่เห็น บนเส้นทางที่มีการสูญหาย การรักษาแย่กว่าอาการ
การแลกเปลี่ยนเป็นที่ยอมรับได้เมื่อทางเลือกคือการไม่มีการเชื่อมต่อเลย และควรบันทึกเป็นข้อยกเว้นที่มีผู้รับผิดชอบแทนที่จะกลืนเป็นเรื่องปกติ
บันทึกการขนส่ง พอร์ต ตัวอย่างคิวรี และผลที่วัดได้ รวมทั้งวันที่ หากไม่มีบันทึกนั้นวิศวกรคนต่อไปจะทำการทดลองซ้ำ และข้อยกเว้นก็จะกลายเป็นสถาปัตยกรรมอย่างเงียบ ๆ
ทำให้การตัดสินใจทบทวนได้
การวินิจฉัยเส้นทางเสื่อมอายุเร็ว กล่องตรงกลางถูกเปลี่ยน การกำหนดค่าเบลดเปลี่ยน ลิงก์ถูกอัปเกรด และเหตุผลของ TCP บน 443 หายไปในขณะที่การกำหนดค่ายังอยู่ ใส่วันที่ทบทวนในข้อยกเว้นและระบุเงื่อนไขที่จะทำให้คุณกลับไปใช้ UDP ได้
ทดสอบทั้งสองการขนส่งด้วยคิวรีเล็กและชุดผลลัพธ์ใหญ่ การจัดลำดับใหม่ปรากฏเป็นการค้างที่ขึ้นกับขนาด ขณะที่ความผิดพลาดของตัวรับฟังหยุดทั้งสองขนาดเท่ากัน