Dante SOCKS บน loopback สำหรับบริการ HTTPS ที่ใช้เฉพาะ WireGuard

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

ตัวอย่างถือว่า Dante 1.4.x ติดตั้งเป็นอินสแตนซ์เฉพาะที่จัดการอยู่บนเวิร์กสเตชัน Linux ที่เชื่อถือได้ โดยมีบัญชีบริการและการกำหนดค่าการบันทึกที่แพ็กเกจให้มาไว้ในที่ของมัน เวิร์กสเตชันเป็นเจ้าของ 10.77.0.2 บนอินเทอร์เฟซ WireGuard ของตน เข้าถึง 10.60.0.20:443 ผ่านอุโมงค์นั้น และชื่อที่ถูกต้องของบริการคือ app.corp.example.

ขั้นตอนที่ 1: ผูกตัวรับฟังกับ loopback เท่านั้น

ใส่ส่วนเครือข่าย วิธีการ และกฎลงในการกำหนดค่าที่ใช้งานของอินสแตนซ์ แทนที่ที่อยู่ตัวอย่าง การตั้งค่าเซิร์ฟเวอร์ทั้งหมดมาก่อนบล็อกกฎ:

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

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

การย้อนกลับของขั้นตอนนี้คือการหยุดอินสแตนซ์ ไฟล์การกำหนดค่าสามารถอยู่บนดิสก์ได้ในขณะที่คุณย้อนกลับ

ขั้นตอนที่ 2: เขียนกฎสองข้อ ไม่ใช่ข้อเดียว

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

สังเกตว่าการกำหนดค่านี้จงใจไม่ทำอะไร: ไม่ขอรหัสผ่าน SOCKS นั่นเหมาะกับโฮสต์โลคอลที่เชื่อถือได้ และไม่ใช่การยืนยันตัวผู้ใช้ กระบวนการอื่นบนเครื่องนั้นก็ใช้ loopback ได้เช่นกัน รักษาการยืนยันตัวของแอปพลิเคชันระยะไกลไว้ และอย่าใช้รูปแบบที่ไม่มีการยืนยันตัวนี้ซ้ำสำหรับผู้ใช้โลคอลที่ไม่น่าเชื่อถือหรือตัวรับฟังที่หันสู่ LAN

ขั้นตอนที่ 3: ตรวจสอบเส้นทางจากต้นทางที่ถูกต้อง

external เลือกที่อยู่ต้นทางขาออก มันไม่ได้ติดตั้งเส้นทาง WireGuard การค้นหาแบบอ่านอย่างเดียวสำหรับต้นทางและปลายทางตัวอย่าง:

ip -4 route get 10.60.0.20 from 10.77.0.2

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

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

ขั้นตอนที่ 4: ทดสอบด้วยตัวตนที่ตั้งใจไว้

หลังจากเจ้าของตรวจสอบการกำหนดค่าที่ติดตั้งและเริ่มอินสแตนซ์ผ่านตัวจัดการบริการ คำขอตัวอย่างคือ:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

ด้วย socks5h Dante ทำการแปลงที่อยู่ปลายทาง แต่ Dante ทำงานบนเวิร์กสเตชันนี้ ดังนั้น การตั้งค่าไม่ได้ส่ง DNS ไปยังปลายทางไกลของอุโมงค์ด้วยตัวเอง. ตัวแปลงที่ได้รับอนุมัติซึ่ง Dante ใช้ต้องคืนที่อยู่ที่อนุญาตสำหรับชื่อนั้น รายการไม่มีพร็อกซีที่ว่างเปล่าป้องกันไม่ให้ข้อยกเว้นที่สืบทอดมาข้าม SOCKS อย่างเงียบ ๆ

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

ขั้นตอนที่ 5: ตัดสินใจว่าเกิดอะไรขึ้นเมื่ออุโมงค์ล้ม

ทดสอบการสูญเสียอุโมงค์และการเริ่มอินสแตนซ์ใหม่ก่อนจะเรียกสิ่งนี้ว่าการผลิต ผู้ดูแลที่เริ่ม Dante หลัง WireGuard ไม่ได้สร้างเส้นทางแบบ fail-closed และไม่ได้สร้าง DNS แบบ fail-closed เช่นกัน ทั้งสองต้องถูกบังคับผ่านเจ้าของเครือข่าย สังเกตว่าแอปพลิเคชันทำอะไรเมื่ออุโมงค์ล่ม: ข้อผิดพลาดที่ชัดเจนเป็นผลลัพธ์ที่ดี การตกลงไปยังตัวแปลงสาธารณะอย่างเงียบ ๆ ไม่ใช่

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