SSH ไปยัง IP สาธารณะของเซิร์ฟเวอร์ WireGuard ล้มเหลวบน Windows

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

แยกที่อยู่สาธารณะของปลายทางออกจากที่อยู่ภายในของอุโมงค์ก่อนแตะรายการเพียร์ การแก้ปัญหานี้ด้วยการแก้ไข AllowedIPs เกือบทุกครั้งทำให้นโยบายอ่อนลงแทนที่จะทำให้เส้นทางถูกต้อง

สิทธิ์การกำหนดเส้นทางและสิทธิ์ของไฟร์วอลล์ต่างกัน

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

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

สิ่งที่ /0 ทำบน Windows

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

กฎเหล่านั้นคือกลไกเบื้องหลังคำว่า kill switch กฎเหล่านี้ถูกเปิดใช้โดยรูปร่างของการกำหนดค่า ไม่ใช่โดยช่องทำเครื่องหมายที่ใช้ชื่อนั้น

ข้อยกเว้นเปลี่ยนรูปแบบการป้องกัน

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

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

ทดสอบเส้นทางการจัดการที่คุณเลือก

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

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

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

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