พร็อกซียังอยู่ที่ที่อยู่ทันเนลเดิมหลังเชื่อมต่อ VPN ใหม่หรือไม่?
การเชื่อมต่อใหม่สามารถทำให้ตัวส่งต่อของคุณผูกกับที่อยู่ที่ทันเนลไม่ได้เป็นเจ้าของอีกต่อไป การตรวจสอบสี่ขั้นตอนตามลำดับ การส่งมอบแบบมีหมายเลข และคำขอทดสอบจริง
การรีสตาร์ทไคลเอนต์ VPN พิสูจน์เพียงว่าทันเนลกลับมาแล้ว ไม่ได้บอกอะไรเกี่ยวกับพร็อกซีที่ได้รับคำสั่งให้ออกผ่านทันเนลนั้น Squid, tinyproxy และตัวส่งต่ออื่น ๆ ส่วนใหญ่จะถือที่อยู่ต้นทางภายในที่หาได้ตอนเริ่มทำงานไว้ จนกว่าอะไรบางอย่างจะบังคับให้โหลดใหม่ เมื่อการเชื่อมต่อใหม่ให้ที่อยู่ทันเนลใหม่ ตัวส่งต่อจะล้มเหลวทุกการเชื่อมต่อขาออก หรือเริ่มออกผ่านเส้นทางปกติของคุณ
ความล้มเหลวอย่างที่สองคืออันตราย ทันเนลทำงาน หน้าเว็บโหลดได้ และมีเพียงที่อยู่ขาออกที่ผิด
เริ่มจากตัวรับฟัง ไม่ใช่ทันเนล
มีที่อยู่สามแห่งในเกม และการเชื่อมต่อใหม่เลื่อนเพียงบางส่วน ตัวรับฟังคือที่ที่เบราว์เซอร์ของคุณชี้ไป ปกติคือ 127.0.0.1 หรือที่อยู่ LAN และไม่สนใจว่าทันเนลเปลี่ยน แหล่งต้นทางภายในขาออกคือสิ่งที่ตัวส่งต่อขอให้เคอร์เนลใช้เมื่อหมุนหมายเลข hop ถัดไป และมันผูกอยู่กับอุปกรณ์ทันเนล ทางออกสาธารณะคือสิ่งที่เว็บเซิร์ฟเวอร์บันทึก และอาจเป็นที่อยู่ที่ถูกแปลหลาย hop ออกไป
การค้นหา IP สาธารณะตอบได้เพียงคำถามสุดท้าย ไม่สามารถบอกได้ว่าตัวส่งต่อควรผูกกับที่อยู่ภายในใด เพราะทางออกสาธารณะหนึ่งแห่งอาจซ่อนแหล่งภายในหลายแหล่ง อ่านที่อยู่จากผู้ที่เป็นเจ้าของการเชื่อมต่อ เอาต์พุตสถานะของไคลเอนต์ ตัวอินเทอร์เฟซเอง หรือเนมสเปซที่ทันเนลอาศัยอยู่ การคว้าอินเทอร์เฟซแรกที่ชื่อดูเหมือนทันเนลให้คำตอบผิดทันทีที่มีโปรไฟล์ที่สอง
เลย์เอาต์ของคอนเทนเนอร์และเนมสเปซทำให้สมมติฐานนี้พังอย่างเงียบ ๆ ตัวส่งต่อในเนมสเปซเครือข่ายหนึ่งไม่สามารถผูกกับทันเนลที่มีอยู่ในอีกเนมสเปซได้ และการแก้ไขการกำหนดค่าไม่ว่าจะมากเพียงใดก็ซ่อมไม่ได้
การตรวจสอบสี่ข้อก่อนแก้ไขอะไร
ทำตามลำดับ การตรวจสอบแรกที่ล้มเหลวคือจุดที่คุณหยุด เพราะข้อต่อไปถือว่าข้อก่อนหน้าถูกต้อง
- ยืนยันว่าทันเนลที่ใช้อยู่คือโปรไฟล์ที่พร็อกซีถูกสร้างขึ้นมา ไม่ใช่โปรไฟล์ที่สองที่เชื่อมต่อเอง
- พิมพ์ที่อยู่ที่อยู่บนอุปกรณ์นั้นตอนนี้และเปรียบเทียบกับที่อยู่ในการกำหนดค่าที่กำลังทำงาน
- ถามตัวส่งต่อว่ามันแก้ไขแหล่งใด ไม่ใช่สิ่งที่ไฟล์บนดิสก์อ้าง
- ยืนยันว่าทราฟฟิกจากตัวส่งต่ออยู่ภายใต้นโยบายการกำหนดเส้นทางและไฟร์วอลล์ที่คุณคาดหวังจริง ๆ
ที่อยู่ของอุปกรณ์ง่าย ip -4 addr show dev tun0 พิมพ์ที่อยู่ปัจจุบัน และ ip -4 route get 1.1.1.1 แสดงว่าเคอร์เนลจะเลือกอินเทอร์เฟซใดสำหรับปลายทางนั้น ตัวส่งต่อที่ผูกที่อยู่แบบเจาะจงจะล้มเหลวอย่างเสียงดังเมื่อที่อยู่หายไป ตัวส่งต่อที่ผูกกับอุปกรณ์ หรือถอยกลับไปใช้แหล่งเริ่มต้น จะทำงานต่อไปและรั่วไหล และนั่นคือผลลัพธ์แบบเงียบ
จับคู่เอกสารกับรุ่นที่คุณเรียกใช้ ไม่ใช่ผลการค้นหาอันดับแรก คำสั่งที่อยู่ขาออกของ Squid มีเอกสารสำหรับ v7 และก่อนหน้า และเอกสารของ v8 ระบุชัดเจนว่าคำสั่งนั้นไม่มีในรุ่นนั้น ดังนั้นสคริปต์ที่สร้างขึ้นรอบคำสั่งนั้นจึงไม่ผ่านขอบเขตนี้ (ดูเอกสารอ้างอิง Squid tcp_outgoing_address) ตรวจสอบด้วยตัวแยกวิเคราะห์ของผลิตภัณฑ์เองก่อนโหลดอะไรใหม่ squid -k parse รายงานข้อผิดพลาดและออกโดยไม่แตะโปรเซสที่กำลังทำงาน
ใส่หมายเลขให้ทุกทันเนลและทิ้งการสลับที่ล้าสมัย
การเชื่อมต่อใหม่คือการส่งมอบ และการส่งมอบต้องมีลำดับ ติดแท็กทุกการเชื่อมต่อที่สังเกตได้ด้วยตัวนับหรือตราเวลาที่เพิ่มขึ้นทุกครั้งที่สร้างสำเร็จ แล้วพาแท็กนั้นเข้าไปในการกำหนดค่าผู้สมัคร เมื่อแท็กบนผู้สมัครเก่ากว่าปัจจุบัน ให้ทิ้งผู้สมัครแทนที่จะนำไปใช้ เพราะการอัปเดตช้าที่เขียนไว้สำหรับทันเนลก่อนหน้าจะเขียนทับการตั้งค่าของทันเนลปัจจุบัน รวมกลุ่มเหตุการณ์ที่กระพริบเพื่อให้ลิงก์ที่สั่นไหวให้การเปลี่ยนผ่านหนึ่งครั้งแทนที่จะเป็นสิบห้า
จัดงานเป็นสี่จังหวะ ทำให้สถานะขาออกเดิมใช้ไม่ได้ รอให้เจ้าของการเชื่อมต่อรายงานว่าเสร็จสิ้น สร้างเฉพาะส่วนที่จัดการ แล้วตรวจสอบและเปิดใช้งานผ่านตัวจัดการบริการ ให้เกียรติการหยุดโดยเจตนาด้วย ความช่วยเหลือที่ยังหมุนหมายเลขทันเนลที่ผู้ใช้ปิดไว้คือบั๊ก ไม่ใช่ความทนทาน
ซ็อกเก็ตที่เปิดอยู่จะไม่ตามที่อยู่ใหม่
การกำหนดค่าตัวส่งต่อใหม่ไม่ได้บอกอะไรเกี่ยวกับการเชื่อมต่อที่สร้างไว้แล้ว มันจะระบายออกหรือตายขึ้นอยู่กับผลิตภัณฑ์ ดังนั้นให้สังเกตพฤติกรรมแทนการสันนิษฐาน
คำขอที่ให้บริการผ่านซ็อกเก็ตที่เปิดไว้ก่อนการสลับยังคงออกผ่านเส้นทางเดิม แม้ว่าการกำหนดค่าใหม่จะถูกต้อง หากสิ่งนั้นสำคัญ ให้ตัดสินใจอย่างชัดเจน อนุญาตหน้าต่างระบายสั้น ๆ และหยุดรับงานใหม่ หรือปิดซ็อกเก็ตเดิมและยอมรับข้อผิดพลาด จากนั้นทดสอบด้วยการเชื่อมต่อใหม่และแยกผลลัพธ์นั้นออกจากการตรวจสอบการระบาย การผูกแหล่งต้นทางก็ไม่ใช่ขอบเขตความปลอดภัยเช่นกัน เมื่อทราฟฟิกต้องไม่แตะเส้นทางปกติเลย ให้บังคับด้วยเครื่องหมายและกฎไฟร์วอลล์ รวมถึง DNS และ IPv6 เพื่อให้การโหลดใหม่ที่ล้มเหลวทำให้พร็อกซีหยุดอย่างชัดเจนแทนที่จะเปิดอยู่
พิสูจน์ทางออกใหม่ด้วยคำขอใหม่
สิ่งสำคัญคือคำขอที่เปิดหลังการเปิดใช้งาน ไม่ใช่ ping และไม่ใช่หน้าที่แคชไว้แล้ว ขอ URL จริงจากพร็อกซีและอ่านที่อยู่ขาออกที่ปลายทางไกลรายงาน แล้วเปรียบเทียบกับมุมมองของไคลเอนต์เองเกี่ยวกับทันเนลเมื่อผู้ให้บริการเปิดเผย
แยกการแยกวิเคราะห์ การโหลดใหม่ และคำขอเป็นคำสั่งแยกกัน เพื่อให้ความล้มเหลวชี้ไปที่ขั้นตอนเดียว สองอย่างแรกไม่เปลี่ยนอะไรเมื่อล้มเหลว และนั่นคือเหตุผลที่มันทำงานก่อนการรีสตาร์ท
squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.comหากการโหลดใหม่ล้มเหลว ให้หยุดบริการและซ่อมส่วนนั้น พร็อกซีที่ให้บริการด้วยทางออกเก่าแย่กว่าการหยุดชะงักสั้น ๆ หากการโหลดใหม่สำเร็จแต่คำขอใหม่ยังออกไปที่ที่ไม่คาดคิด ให้กลับไปตรวจสอบการกำหนดเส้นทางแทนการแก้ไขที่อยู่อีกครั้ง บันทึกรุ่นของทันเนลที่คุณตรวจสอบไว้ เพื่อให้การเชื่อมต่อใหม่ครั้งถัดไปมีสิ่งที่เป็นรูปธรรมให้เปรียบเทียบ