VPN เปิดอยู่แต่ localhost ใช้งานไม่ได้: ชื่อ พร็อกซี หรือ bind?
เมื่อคำต่อท้ายการค้นหาหรือพร็อกซีเข้าควบคุม localhost ก็ไม่ได้หมายถึงเครื่องของคุณอีกต่อไป แก้ชื่อก่อน จากนั้นเส้นทาง แล้วจึงสตริงการเชื่อมต่อของเครื่องมือ
เซิร์ฟเวอร์สำหรับพัฒนาของคุณตอบกลับเมื่อนาทีที่แล้ว และตอนนี้เมื่อทุนเนลขึ้น คำขอหมดเวลาด้วยชื่อโฮสต์ที่คุณไม่เคยพิมพ์ สองกลไกอธิบายเกือบทุกกรณี และจากภายนอกทั้งสองดูเหมือนกัน คำต่อท้ายการค้นหาเปลี่ยนชื่อสั้นให้เป็นชื่อองค์กร ขณะที่พร็อกซีส่งทราฟฟิกลูปแบ็กไปยังโฮสต์ที่ไม่สามารถเข้าถึงได้ การแยกสองสิ่งนี้ใช้คำถามเดียวและประหยัดกฎไฟร์วอลล์ที่คุณกำลังจะเขียน
เมื่อ localhost แก้เข้าโซนองค์กร
ตรวจสอบว่าชื่อแก้เป็นอะไรในขณะที่ทุนเนลขึ้น จากนั้นรันคำถามเดิมโดยปิดทุนเนลแล้วเปรียบเทียบคำตอบทั้งสอง ตัวบ่งชี้คือที่อยู่ในช่วงองค์กรตรงที่คุณคาดว่าจะเห็น 127.0.0.1 บันทึกอย่าง localhost.mycompany.corp ชนะรายการลูปแบ็กทันทีที่ไคลเอนต์เพิ่มคำต่อท้ายนั้นลงในรายการค้นหา และคำขอเดินทางไปยังโฮสต์ส่วนตัวที่ไม่มีอะไรฟังอยู่บนพอร์ตนั้น อ่านรายการค้นหาแทนการเดา เพราะไคลเอนต์สามารถเพิ่มได้มากกว่าหนึ่งโดเมนและลำดับเป็นตัวกำหนดว่าจะลองผู้สมัครรายใดก่อน
getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080
แทนที่ชื่อโฮสต์ด้วยที่อยู่ตามตัวอักษรในแอปพลิเคชัน ไคลเอนต์ฐานข้อมูล หรือ URL ของโน้ตบุ๊ก แล้วทำคำขอซ้ำ ถ้าความล้มเหลวหายไปแสดงว่าคุณมีปัญหาการตั้งชื่อและทุนเนลเป็นเพียงตัวกระตุ้น ถ้ายังคงอยู่ ผู้ฟังหรือเส้นทางคือผู้ต้องสงสัยรายถัดไปและชื่อเป็นเพียงร่องรอยลวง
การตั้งค่าพร็อกซีที่ดักลูปแบ็ก
พร็อกซีของระบบที่ถูกใช้เมื่อทุนเนลขึ้นจะยอมรับคำขอไปยัง 127.0.0.1 และส่งต่อไปยังพร็อกซีระยะไกลที่ไม่รู้ว่าคุณหมายถึงอะไร รายการยกเว้นที่ว่างเปล่าทำให้คำขอในเครื่องกลายเป็นคำขอระยะไกล และข้อความข้อผิดพลาดแทบไม่บอกเช่นนั้น เพิ่มที่อยู่ลูปแบ็กลงในรายการยกเว้นสำหรับทั้งเซสชันไม่ใช่คำสั่งเดียว แล้วยืนยันว่าเครื่องมือเคารพสิ่งนั้นก่อนสรุปอะไรเกี่ยวกับเครือข่าย
เฟรมเวิร์กของแอปพลิเคชันอ่านตัวแปรสภาพแวดล้อมของตัวเองและบางครั้งอ่านไฟล์กำหนดค่าของตัวเอง ดังนั้นการยกเว้นที่ใช้ได้กับเครื่องมือหนึ่งจึงไม่ได้พิสูจน์สิ่งใดสำหรับเครื่องมือถัดไป เบราว์เซอร์เพิ่มรายละเอียด: เบราว์เซอร์ที่ใช้ Chromium ข้ามพร็อกซีสำหรับลูปแบ็กโดยปริยาย และโทเค็นยกเว้นสามารถลบพฤติกรรมนั้นได้ ตรวจสอบการตัดสินใจของพร็อกซีจริงแทนการสมมติว่าการตั้งค่าระบบปฏิบัติการคือเรื่องทั้งหมด สองคำสั่งตัดสินสิ่งนี้สำหรับทุกอย่างที่เริ่มจากเชลล์
curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool
ที่อยู่ bind เป็นตัวกำหนดว่าใครเชื่อมต่อได้
เซิร์ฟเวอร์ที่เริ่มบน 127.0.0.1 ยอมรับการเชื่อมต่อจากเครื่องนั้นเท่านั้น ซึ่งโดยปกติเป็นค่าเริ่มต้นที่ถูกต้องสำหรับการพัฒนา เซิร์ฟเวอร์บน 0.0.0.0 ตอบบนทุกอินเทอร์เฟซรวมถึงอะแดปเตอร์ VPN ซึ่งเป็นการเปิดเผยมากกว่าที่คนส่วนใหญ่ตั้งใจ เมื่อที่อยู่ลูปแบ็กตามตัวอักษรล้มเหลว ให้ตรวจสอบ bind ก่อนสิ่งอื่นใด
ดูซ็อกเก็ตที่กำลังฟังและบันทึกที่อยู่ที่ผูกอยู่ ไม่ใช่แค่พอร์ต ถ้าอุปกรณ์อื่นหรือคอนเทนเนอร์ต้องเข้าถึงบริการผ่านทุนเนล ให้ผูกกับอินเทอร์เฟซเฉพาะที่จะใช้และอนุญาตพอร์ตนั้นอย่างตั้งใจ ถ้าเครื่องของคุณเองเท่านั้นที่ต้องการ ให้คง bind แคบไว้และแก้ไคลเอนต์แทนการขยายเซิร์ฟเวอร์ การส่งต่อพอร์ตหรือชั้นทุนเนลสามารถเชื่อมทั้งสองได้ แต่แต่ละอย่างเพิ่มองค์ประกอบที่ภายหลังจะต้องดีบักเอง
ที่ที่เครื่องมือดีบักคาดหวัง LAN
เครื่องมือดีบักมีสมมติฐานที่ทุนเนลทำลายอย่างเงียบ ๆ สะพานดีบักโทรศัพท์สูญเสียอุปกรณ์เมื่อ VPN จับซับเน็ตของอุปกรณ์ ดังนั้นการเชื่อมต่อใหม่ผ่านที่อยู่ LAN หรือสายเคเบิลจึงหลีกเลี่ยงความขัดแย้ง ฮับอัตโนมัติของเบราว์เซอร์หมดเวลาเมื่อฮับเข้าถึงได้ผ่านพร็อกซีเท่านั้น หรือเมื่อไฟร์วอลล์ในเครื่องทิ้งพอร์ตควบคุม ดีบักเกอร์ระยะไกลอาจต้องยกระดับสิทธิ์และที่อยู่ลูปแบ็กในจุดที่ไคลเอนต์เขียนเส้นทางใหม่
ระบุพอร์ตควบคุมและพอร์ตข้อมูลแยกจากกัน เพราะบ่อยครั้งที่หนึ่งรอดชีวิตและอีกอันไม่ จากนั้นตัดสินว่าการแก้ไขเป็นของการกำหนดค่าเครื่องมือ อยู่ในเส้นทางสำหรับซับเน็ตนั้น หรือ กฎทุนเนลแบบแยกส่วน การแก้ไขไฟล์ hosts บนเครื่องนักพัฒนาทุกเครื่องขยายได้แย่ที่สุดและถูกลืมก่อน ควรเลือกการตั้งค่าที่อยู่กับโปรไฟล์และใครก็ตามที่เป็นเจ้าของทุนเนลสามารถตรวจสอบได้
หยุดที่ขั้นแรกที่ล้มเหลว
ไล่ลงสามขั้น: แก้ชื่อ เปิดซ็อกเก็ตไปยังที่อยู่ตามตัวอักษร แล้วปล่อยให้เครื่องมือสร้างการเชื่อมต่อของตัวเอง แต่ละขั้นกำจัดชั้นหนึ่ง ดังนั้นความล้มเหลวแรกจะระบุชั้นที่ต้องแก้และทุกอย่างหลังจากนั้นยังไม่ได้ทดสอบ จดผลลัพธ์ก่อนเปลี่ยนอะไร เพราะการแก้ไขที่ใช้ก่อนการวัดแยกจากโชคไม่ได้ ถ้าความพยายามแรกล้มเหลวและการลองใหม่ได้ผล ทุนเนลอาจยังไม่พร้อมเมื่อเครื่องมือเริ่ม
แทนที่การรอแบบคงที่ด้วยการตรวจสอบความพร้อมแบบจำกัดที่รอเส้นทาง และเก็บขั้นที่ล้มเหลวไว้ในบันทึกเพื่อให้คนถัดไปเห็นว่าหยุดที่ใด เครื่องมือที่ฟื้นตัวเองไม่ได้ถูกแก้ไข มันแค่โชคดี และโชคหมดบนเครื่องของคนอื่น เปลี่ยนทุนเนลเป็นอย่างสุดท้าย และเฉพาะขั้นที่ล้มเหลวจริงเท่านั้น ลำดับนั้นยังเป็นทางกลับสู่บิลด์ที่ใช้งานได้สั้นที่สุด เพราะมันกันคุณไม่ให้สร้างองค์ประกอบที่ไม่เคยเกี่ยวข้องขึ้นใหม่