การปรับ MSS ของ TCP บนเกตเวย์ Linux IPsec: แก้อะไร

Ping ทำงานได้ SSH ทำงานได้ หน้าเว็บเล็กโหลดได้ จากนั้นทุกการตอบกลับขนาดใหญ่จะค้างจนหมดเวลา รูปแบบคลาสสิกชี้ไปที่ขนาดแพ็กเก็ตไม่ใช่การเข้าถึง: เส้นทางขนส่งแฮนด์เชกและสองสามกิโลไบต์แรก จากนั้นเซกเมนต์ขนาดเต็มก็หายไป บนเกตเวย์ Linux IPsec กฎ TCP MSS มักเป็นวิธีแก้ แต่เฉพาะเมื่อคุณเข้าใจว่ามันเปลี่ยนอะไรและแพ็กเก็ตที่มันแตะอยู่ที่ไหนจริง ๆ ลำดับด้านล่างติดตามแพ็กเก็ตตั้งแต่ symptom ไปจนถึงการวางกฎ คุณจึงหยุดได้ทันทีที่คำอธิบายไม่ตรงอีกต่อไป

อาการที่บ่งชี้ถึง MSS

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

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

กฎ TCPMSS ทำอะไรและไม่ทำอะไร

กฎนี้เขียนตัวเลือก MSS ในแพ็กเก็ตแฮนด์เชกของ TCP ขณะที่ผ่านไป มันไม่ได้ตั้ง MTU ของอินเทอร์เฟซทันเนล ไม่ได้เปลี่ยนนโยบาย IPsec และบนเคอร์เนลปัจจุบันมันเพียงลดค่าที่ประกาศแทนที่จะเพิ่มค่าที่เล็กกว่าอยู่แล้ว มันยังแตะเฉพาะ TCP เพย์โหลด UDP พฤติกรรม DNS และตัวเลือกทราฟฟิกที่เจรจาแล้วอยู่นอกขอบเขตของมัน

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

วางกฎบนเส้นทาง TCP ภายใน

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

ในแง่ของ iptables กฎนี้อยู่ในตาราง mangle บนเส้นทางส่งต่อ จำกัดเฉพาะแพ็กเก็ตแฮนด์เชก: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270 ตัวเลขเป็นตัวอย่าง ไม่ใช่ค่าคงที่สากล จงหามันจากโอเวอร์เฮดของการห่อหุ้มและ MTU จริงของเส้นทาง nftables ที่เทียบเท่าตั้งขนาดเซกเมนต์สูงสุดในเชน forward หรือ postrouting

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

เคารพเจ้าของไฟร์วอลล์และลำดับ NAT

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

การแปลต้นทางเป็นการตัดสินใจแยกต่างหากที่มักมีปฏิสัมพันธ์กับข้อนี้ ข้อยกเว้นที่วางก่อนกฎ masquerade ทั่วไปป้องกันไม่ให้ทราฟฟิกที่ได้รับการป้องกันสูญเสียต้นทางที่นโยบายต้องการ มันไม่ได้แก้ปัญหาขนาด และกฎขนาดไม่ได้แก้ปัญหาการแปล

ตรวจสอบอย่างแคบ แล้วหยุด

เปิดการเชื่อมต่อใหม่ไปยังบริการที่ล้มเหลวและเฝ้าดูทั้งแอปพลิเคชันและตัวนับของกฎ หากการค้างหายไป คุณมีหลักฐานเกี่ยวกับเส้นทาง TCP นั้นด้วยการห่อหุ้มนั้น คุณไม่มีหลักฐานว่าโปรโตคอล VPN ทุกตัวเข้ากันได้ แอปพลิเคชัน UDP ทุกตัวได้รับการแก้ไข หรือบริการต้นน้ำบางบริการเป็นสาเหตุเดิม

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