พอร์ต VPN เงียบ? ตัวรับฟัง ที่อยู่ผูกพอร์ต หรือไฟร์วอลล์ของโฮสต์

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

สมมติว่าคุณเข้าสู่เซิร์ฟเวอร์ได้ และไคลเอนต์เป็นโปรไฟล์จริงไม่ใช่ตัวสแกน สมมติฐานทั้งสองสำคัญ เพราะการตรวจแบบทั่วไปตอบคำถามเฉพาะโปรโตคอลไม่ได้

มีซ็อกเก็ตอยู่จริงหรือไม่

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

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

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

ซ็อกเก็ตตอบบนที่อยู่และตระกูลใด

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

การจำกัดรายการให้เหลือพอร์ตเดียวทำให้ยังอ่านได้เมื่อโฮสต์รันหลายบริการ ตัวกรอง sport ใช้พอร์ตร่วมกับทรานสปอร์ตที่คุณกำลังทดสอบ:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

คอลัมน์โปรโตคอลเปลี่ยนคำตอบทั้งหมด

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

UDP มีรอยพับที่สอง: การตรวจที่ไม่ผ่านการยืนยันตัวตนไม่ใช่ข้อผิดพลาดที่บริการต้องตอบ การสแกนที่รายงานว่าพอร์ตเงียบได้วัดความระมัดระวังของบริการ ไม่ใช่ความพร้อมใช้งาน ดังนั้นทดสอบด้วยไคลเอนต์และโปรไฟล์จริง

หนึ่งความพยายาม สามที่ให้ดู

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

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

ตั้งชื่อขั้นตอนก่อนเปลี่ยนกฎ

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

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