Tor พร้อมก่อน VPN จัดลำดับประตูเริ่มต้นให้ถูกต้อง

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

ขั้นตอนที่ 1 เลือกการขนส่งที่คุณมีจริง ๆ

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

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

เขียนการขนส่งที่เลือกไว้ในรันบุ๊ก เพราะทุกการตรวจสอบหลังจากนั้นขึ้นอยู่กับมัน

ขั้นตอนที่ 2 อ่านเฟส bootstrap ไม่ใช่รายการโปรเซส

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

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

อ่านเฟสหนึ่งครั้งตอนเริ่มต้น แล้วสมัครรับเหตุการณ์ความคืบหน้าสำหรับมุมมองสด

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

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

ขั้นตอนที่ 3 รอเหตุการณ์วงจรของไคลเอนต์

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

ถือว่าเหตุการณ์เป็นการอนุญาตให้ลอง ไม่ใช่การรับประกันเกี่ยวกับปลายทางใดปลายทางหนึ่ง นโยบายขาออกยังสามารถปฏิเสธคู่ปลายทางไกลได้ และแฮนด์เชกของ VPN เองก็ยังล้มเหลวได้ด้วยเหตุผลที่ไม่เกี่ยวข้องกับ Tor

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

ขั้นตอนที่ 4 ผูกประตู VPN กับแฮนด์เชกของมันเอง

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

ตัดสินใจว่าจะเกิดอะไรขึ้นเมื่อคู่ปลายทางเข้าถึงไม่ได้ ก่อนที่คุณจะต้องรู้ การลองใหม่แบบจำกัดพร้อมความล้มเหลวที่มองเห็นได้นั้นดูแลง่ายกว่าวงจรไม่สิ้นสุด และให้ระบบเฝ้าติดตามมีอะไรให้แจ้งเตือน การตัดสินใจเดียวกันนี้ใช้กับผู้ให้บริการด้วย หาก Tor เริ่มใหม่ VPN ต้องถูกถอดและผูกประตูใหม่ ไม่ใช่ปล่อยให้ทำงานบนวงจรที่ตายแล้ว

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

ตรวจสอบสี่การเปลี่ยนผ่านที่คุณต้องผ่านไปให้ได้

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

รันพวกมันอย่างตั้งใจ ทีละตัว และอ่านการเปลี่ยนแปลงสถานะแทนรายการโปรเซส

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

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