โทรศัพท์เปิดหน้าไม่ได้: ตรวจสอบที่อยู่ที่รอรับการเชื่อมต่อ

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

ไล่ตามลำดับคือ socket การตั้งค่า bind กฎไฟร์วอลล์ และ URL

socket ตอบคำถามที่แคบกว่า

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

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

IPv6 เพิ่มกรณีที่สาม เพราะ socket อาจยอมรับ IPv4 และ IPv6 ขึ้นกับตัวเลือกที่มองข้ามได้ง่าย อ่านตระกูลที่อยู่ในรายการ รายการไวลด์การ์ดของตระกูลหนึ่งไม่ได้อธิบายอีกตระกูล

อ่านที่อยู่ที่รอรับการเชื่อมต่อ

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

Get-NetTCPConnection -State Listen -LocalPort 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 8080).OwningProcess
ipconfig | Select-String -Pattern 'IPv4'
Get-NetFirewallRule -DisplayName '*8080*' | Format-Table DisplayName,Enabled,Profile,Direction,Action

ที่อยู่ภายใน 127.0.0.1 ตัดสินคำถามนี้: การเปลี่ยนไฟร์วอลล์ไม่ช่วย เพราะแอปพลิเคชันไม่ได้รอรับบนอินเทอร์เฟซ VPN ไวลด์การ์ดหรือที่อยู่ VPN หมายความว่า socket เรียบร้อยและขอบเขตถัดไปมีผล

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

เปลี่ยน bind ผ่านแอปพลิเคชัน

ใช้ตัวเลือกที่อยู่สำหรับรอรับที่เฟรมเวิร์กจัดทำเอกสารไว้ แล้วรีสตาร์ตกระบวนการ หากแล็ปท็อปเป็นเจ้าของที่อยู่ส่วนตัว 10.77.0.1 URL ของโทรศัพท์จะเป็น http://10.77.0.1:8080/ และที่อยู่นั้นต้องถูกส่งผ่านเส้นทาง VPN ไม่มีอย่างอื่นในการตั้งค่าที่เปลี่ยน

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

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

เปิดกฎเดียว ไม่ใช่ทั้งเครือข่าย

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

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

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

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