SSTP ยึดพอร์ต 443: ทำไม Apache ถึงไม่เริ่มทำงาน

Apache หยุดตอบสนองบน 443 ในบ่ายวันที่มีคนเปิดใช้การเชื่อมต่อ VPN ขาเข้า และล็อกข้อผิดพลาดก็โทษ bind แทนการจองที่อยู่เบื้องหลัง Windows Routing and Remote Access เปิดใช้ SSTP ในขณะนั้น และตัวรับฟัง SSTP เรียกร้อง TCP 443 ผ่านสแตก HTTP ก่อนที่ไคลเอนต์ใดจะถูกตรวจสอบสิทธิ์ การเรียกร้องยังคงอยู่แม้ใบรับรองจะหายไป ชื่อผิด หรือทุก handshake ถูกปฏิเสธ VPN ที่ไม่มีใครเข้าได้จึงยังคงยึดพอร์ตไว้ อ่านตารางการฟังก่อน PID ที่ถือ 443 เป็นผู้ตัดสินว่าการแก้ไขใดด้านล่างนี้เปิดให้คุณ

การจองอยู่ได้นานกว่าใบรับรองที่พัง

SSTP ห่อ PPP ไว้ในเซสชัน TLS จึงต้องใช้ 443 และจึงผ่านพร็อกซี่ที่ทิ้งอุโมงค์อื่น ตัวรับฟังไม่ใช่ซ็อกเก็ตที่บริการ VPN เปิดให้ตัวเอง: SstpSvc ลงทะเบียนกับไดรเวอร์ HTTP ของเคอร์เนล พอร์ตจึงยังถูกจองไว้ตราบที่บริการทำงาน การลงทะเบียนนั้นไม่เคยสอบถามใบรับรอง ชื่อที่หมดอายุ subject ที่ไม่ตรงกัน หรือการไม่มีใบรับรองเลยจึงทิ้ง 443 ให้ถูกยึดไว้ ความล้มเหลวจึงแยกเป็นสองทาง: handshake ที่ถูกปฏิเสธไปอยู่ในล็อก System ภายใต้ RasSstp ขณะที่เว็บเซิร์ฟเวอร์ทำได้เพียงรายงานว่าผูกไม่ได้

netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"

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

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

IIS ใช้ไดรเวอร์ร่วมกัน Apache เปิดซ็อกเก็ต

IIS ส่ง bindings ให้ไดรเวอร์เคอร์เนลตัวเดียวกับที่ SSTP ใช้ และไดรเวอร์นั้นแยกการเชื่อมต่อขาเข้าตามชื่อโฮสต์และคำนำหน้า URL ทั้งสองบริการจึงถูกสั่งให้ต้องการ 443 ได้โดยไม่มีตัวใดล้มเหลว Apache และ nginx ทำตรงกันข้าม: เรียก bind บนซ็อกเก็ตของตัวเอง และระบบปฏิบัติการปฏิเสธเพราะที่อยู่ถูกยึดไปแล้ว ไม่มีอะไรผิดในทั้งสองการตั้งค่า ความต่างอยู่ที่ API ใดเป็นเจ้าของพอร์ต นั่นคือเหตุผลที่การเปิด VPN ทำให้ไซต์หนึ่งล่มบนโฮสต์หนึ่งและปล่อยให้ไซต์ที่เหมือนกันบนอีกโฮสต์ไม่ถูกแตะต้อง

ความไม่สมมาตรนี้กำหนดรูปร่างของการซ่อม ถ้า IIS เป็นประตูหน้าอยู่แล้ว ความขัดแย้งจะกลายเป็นเรื่องของคำนำหน้า bindings และใบรับรอง ถ้า Apache เป็นประตูหน้า ไม่มันก็ย้ายออกจาก 443 หรือตัวรับฟัง SSTP ย้าย และหัวข้อถัดไปครอบคลุมทั้งสองทาง

เลือกว่าบริการใดจะเก็บ 443 ไว้

พอร์ตของตัวรับฟังอยู่ในค่ารีจิสทรีเดียว คือ DWORD ฐานสิบภายใต้คีย์พารามิเตอร์ของ Sstpsvc เปลี่ยนค่า รีสตาร์ท Routing and Remote Access และยืนยันจากตารางการฟังว่าพอร์ตเก่าว่างแล้ว

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess

เลือกพอร์ตที่ไม่มีอะไรอื่นบนโฮสต์ต้องการ และพิมพ์เป็นฐานสิบ: reg add เก็บ DWORD ตามที่เขียนไว้ทุกประการ ค่าที่ตั้งใจให้เป็นฐานสิบหกจึงไปตกเป็นพอร์ตอื่น ถ้าคำสั่งบอกว่าไม่มีค่านี้ บรรทัดที่สองจะสร้างให้ Restart-Service RemoteAccess ตัดทุกคนที่เชื่อมต่ออยู่ออก ซึ่งคุ้มที่จะวางแผนไว้ แล้วรันการตรวจสอบการฟังอีกครั้ง เพราะรายการเก่าบน 443 หมายความว่าบริการยังเก็บการลงทะเบียนเดิมไว้

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

อีกทางหนึ่งเก็บ 443 ไว้ที่ IIS และถือว่า Apache เป็น backend ที่พร็อกซี่ส่งต่อไป วิธีนี้รักษาค่าเริ่มต้นของ SSTP และเหลือเจ้าของพอร์ตเพียงรายเดียว โดยมีต้นทุนเป็นหัวข้อที่ถูกส่งต่อ ที่อยู่ไคลเอนต์ที่แอปพลิเคชันไม่เห็นโดยตรงอีกต่อไป และ backend ที่ต้องพูดโปรโตคอลที่พร็อกซี่ส่งจริง

พิสูจน์เจ้าของ ใบรับรอง และ handshake ตามลำดับ

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

netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20

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

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