ทำไมกฎพอร์ตต้นทางจึงทำให้เส้นทาง SSH ของคุณเส้นหนึ่งพัง

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

สองทางเข้า หนึ่งพอร์ตบริการ

โฮสต์มีที่อยู่ฝั่ง LAN และที่อยู่ VPN และ sshd รับฟังทั้งสอง ดังนั้นเซสชันตรงและเซสชันอุโมงค์จึงใช้พอร์ตบริการร่วมกันและต่างกันเพียงที่อยู่ภายในใดที่รับการเชื่อมต่อ

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

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

อ่านกฎ แล้วอ่านตาราง

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

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

ip -4 rule show
ip route show table 100
ip route show table main

ผลลัพธ์ทั้งสองร่วมกันอธิบายผลลัพธ์ อย่างใดอย่างหนึ่งเพียงลำพังชวนให้สรุปผิด

จำกัดกฎไว้ที่โฟลว์ที่คุณหมายถึง

คุณลักษณะที่แยกสองทางเข้าคือที่อยู่ต้นทางภายใน กฎที่จับคู่ที่อยู่นั้นส่งเฉพาะเซสชันอุโมงค์ไปยังตารางส่วนตัว และปล่อยเซสชันตรงไว้บนตารางหลัก

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

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

แยกผู้รับฟัง สิทธิ์ และการเลือกคำตอบออกจากกัน

สามสิ่งแยกกันต้องเป็นจริงก่อนเซสชันจะทำงาน ที่อยู่มีอยู่ บริการรับฟังอยู่บนนั้น และคำตอบหาเส้นทางกลับได้ การเปลี่ยนเส้นทางแก้ได้เพียงข้อที่สาม

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

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

พิสูจน์ด้วยเซสชันใหม่ ไม่ใช่เซสชันเก่า

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

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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