โฮสต์ไปถึงเพื่อน IPsec ได้ แต่คอนเทนเนอร์ Docker ไม่ได้

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

แนวทางด้านล่างติดตามปลายทางเดียวผ่านสองต้นทาง โดยอ่านสถานะก่อนเปลี่ยนแปลงสิ่งใด

เริ่มจากปลายทางเดียวและสองต้นทาง

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

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

อ่านนโยบายก่อนแตะ Docker

การตรวจสอบโฮสต์แบบอ่านอย่างเดียวครอบคลุมการตัดสินใจเรื่องเส้นทาง ฐานข้อมูลนโยบาย และกฎที่เลือกระหว่างกัน:

ip rule show
ip route show table all
ip xfrm policy

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

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

ตรวจสอบการกรองและการแปลตามลำดับ

ไฟร์วอลล์บริดจ์ Linux ของ Docker สามารถบล็อกการส่งต่อได้โดยไม่ขึ้นกับ IPsec เมื่อใช้แบ็กเอนด์ iptables ให้ตรวจเส้นทาง FORWARD และการตัดสินใจของ DOCKER-USER โดยจำไว้ว่ากฎที่เพิ่มหลังคำตัดสินก่อนหน้าอาจไม่เคยทำงานเลย แบ็กเอนด์ nftables ผสานต่างออกไป ดังนั้นอย่าสร้างเชน DOCKER-USER เพียงเพราะตัวอย่าง iptables เรียกชื่อนั้น ตรวจว่า daemon ของคุณใช้แบ็กเอนด์ใดจริง

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

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

จากนั้นตัดสินว่าจะใช้เส้นทางหรือการแปล

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

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

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

ตรวจสอบด้วยการเชื่อมต่อใหม่ ไม่ใช่การรีสตาร์ต

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

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