Ping ทำงานแต่ SSH ล้มเหลวผ่าน VPN: ด่านไหนพัง?

การตอบกลับ ping และการล็อกอิน SSH ที่ถูกปฏิเสธเป็นจริงพร้อมกันได้ และคู่นี้ไม่ได้ชี้ว่าอุโมงค์มีปัญหา การตอบกลับแบบ echo และการเชื่อมต่อ TCP ไปยังพอร์ต 22 เป็นการทดสอบที่ต่างกันด้วยตัวเลือกต่างกัน นโยบายต่างกัน และบ่อยครั้งปลายทางก็ต่างกัน บันทึกความพยายาม SSH ที่ตั้งใจหนึ่งครั้ง แล้วระบุด่านสุดท้ายที่มันไปถึง หลักฐานชิ้นเดียวนั้นแทนที่การแก้ไขคอนฟิกูเรชันแบบคาดเดาหลายสิบครั้ง

บันทึกความพยายามหนึ่งครั้ง ไม่ใช่เซสชันของการสะกิดหลายหน

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

ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]

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

ด่านที่หนึ่งและสอง: TCP ก่อน SSH

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

nc -vz 10.90.4.20 22
ip route get 10.90.4.20
tcpdump -ni any 'host 10.90.4.20 and port 22'

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

ด่านที่สาม: คีย์ของใครตอบ

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

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

ด่านที่สี่และห้า: บัญชีกับการอนุญาต

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

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

การย้อนกลับและบันทึกที่คุณเก็บ

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

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