Score:0

การกำหนดเส้นทาง OpenVPN ระหว่างเครือข่ายย่อยและ LAN ไม่ทำงาน

ธง cn

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

โดยพื้นฐานแล้วฉันพยายามให้กลุ่มผู้ใช้ต่างๆ เข้าถึงบริการเว็บ ทั้ง openvpn และ webservice ทำงานในอินสแตนซ์นักเทียบท่า

ความช่วยเหลือหรือคำแนะนำใด ๆ ได้รับการชื่นชมอย่างมากเนื่องจากฉันกำลังต่อสู้กับสิ่งนี้ตั้งแต่ 2 สัปดาห์แล้ว

ขั้นตอนที่ดำเนินการ: ฉันตั้งค่า openvpn conf ด้วยเส้นทางและไคลเอนต์ถึงไคลเอนต์

เซิร์ฟเวอร์ 192.168.255.0 255.255.255.0
กริยา 3
คีย์ /etc/openvpn/pki/private/xxxx.key
ca /etc/openvpn/pki/ca.crt
ใบรับรอง /etc/openvpn/pki/issued/xxxx.crt
dh /etc/openvpn/pki/dh.pem
tls-auth /etc/openvpn/pki/ta.key
ทิศทางคีย์ 0
Keepalive 10 60
คีย์คงอยู่
คงอยู่-tun

โปรโตคอล udp
# พึ่งพา Docker เพื่อทำการแมปพอร์ตภายใน 1194 เสมอ
พอร์ต 1194
ทุนพัฒนา
สถานะ /tmp/openvpn-status.log
ซับเน็ตโทโพโลยี
ไคลเอ็นต์-config-dir ccd

ผู้ใช้ไม่มีใคร
กลุ่มโนกรุ๊ป
comp-lzo ไม่
ลูกค้าต่อลูกค้า

### การกำหนดค่าเส้นทางด้านล่าง
เส้นทาง 192.168.254.0 255.255.255.0
เส้นทาง 10.0.0.0 255.255.255.0
เส้นทาง 10.0.1.0 255.255.255.0
เส้นทาง 10.0.3.0 255.255.255.0
เส้นทาง 10.0.4.0 255.255.255.0
เส้นทาง 10.0.5.0 255.255.255.0

### กดการกำหนดค่าด้านล่าง
#push "บล็อกภายนอก DNS"
กด "dhcp-option DNS 8.8.8.8"
กด "dhcp-option DNS 8.8.4.4"
กด "comp-lzo no"
กด "เส้นทาง 172.17.0.0 255.255.255.0"

ฉันกำหนดค่าการส่งต่อโดยการตั้งค่า net.ipv4.ip_forward = 1 ใน /etc/sysctl.conf

ฉันกำหนดค่ากฎ iptable

-P อินพุตยอมรับ
-P ยอมรับไปข้างหน้า
-P เอาต์พุตยอมรับ
-A ไปข้างหน้า -s 192.168.255.0/24 -d 172.17.0.0/24 -i tun0 -j ยอมรับ
-A ไปข้างหน้า -j ยอมรับ
-A ส่งต่อ -s 192.168.255.0/24 -d 10.0.0.0/24 -i tun0 -j ยอมรับ

แต่จาก IP ในช่วงเซิร์ฟเวอร์ (192.168.255.2) ไม่สามารถ ping หรือเข้าถึงอะไรได้ (172.17.0.4 หรือ 10.0.0.1)

เส้นทางการติดตามสิ้นสุดที่เกตเวย์

% การติดตามเส้นทาง 10.0.0.1
ติดตามเส้นทางไปยัง 10.0.0.1 (10.0.0.1), สูงสุด 64 hops, 52 แพ็คเก็ตไบต์
1 192.168.88.1 (192.168.88.1) 12.279 มิลลิวินาที 3.251 มิลลิวินาที 1.882 มิลลิวินาที
2 *

นี่คือบันทึกจากลูกค้าของฉันด้วย

2022-04-30 06:24:38.983758 *Tunnelblick: macOS 12.3.1 (21E258); Tunnelblick 3.8.5beta05 (รุ่น 5650)
2022-04-30 06:24:39.446714 *Tunnelblick: พยายามเชื่อมต่อกับ greenhive_master โดยใช้ shadow copy; ตั้งเนมเซิร์ฟเวอร์ = 769; ตรวจสอบการเชื่อมต่อ
2022-04-30 06:24:39.450786 *Tunnelblick: openvpnstart เริ่มต้น greenhive_master.tblk 52399 769 0 1 0 34652464 -ptADGNWradsgnw 2.4.10-openssl-1.1.1j
2022-04-30 06:24:39.477788 *Tunnelblick: openvpnstart เริ่มต้น OpenVPN
2022-04-30 06:24:39.857743 OpenVPN 2.4.10 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] สร้างเมื่อ 25 ก.พ. 2021
2022-04-30 06:24:39.857947 รุ่นของไลบรารี: OpenSSL 1.1.1j 16 ก.พ. 2021, LZO 2.10
2022-04-30 06:24:39.859534 การจัดการ: ซ็อกเก็ต TCP กำลังฟังบน [AF_INET]127.0.0.1:52399
2022-04-30 06:24:39.859562 ต้องการการระงับจากอินเทอร์เฟซการจัดการ กำลังรอ...
2022-04-30 06:24:40.078894 *Tunnelblick: openvpnstart บันทึก:
     OpenVPN เริ่มต้นสำเร็จ
     คำสั่งที่ใช้เพื่อเริ่ม OpenVPN (หนึ่งอาร์กิวเมนต์ต่อบรรทัดที่แสดง):
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.4.10-openssl-1.1.1j/openvpn
          --ภูต
          --log /Library/Application Support/Tunnelblick/Logs/-SUsers-Srobertk-SLibrary-SApplication Support-STunnelblick-SConfigurations-Sgreenhive_master.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_34652464.52399.openvpn.log
          --cd /Library/Application Support/Tunnelblick/Users/robertk/greenhive_master.tblk/Contents/Resources
          --เครื่องอ่าน-เอาท์พุท
          --setenv IV_GUI_VER "net.tunnelblick.tunnelblick 5650 3.8.5beta05 (รุ่น 5650)"
          --คำกริยา 3
          --config /Library/Application Support/Tunnelblick/Users/robertk/greenhive_master.tblk/Contents/Resources/config.ovpn
          --setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Users/robertk/greenhive_master.tblk/Contents/Resources
          --คำกริยา 3
          --cd /Library/Application Support/Tunnelblick/Users/robertk/greenhive_master.tblk/Contents/Resources
          --การจัดการ 127.0.0.1 52399 /Library/Application Support/Tunnelblick/geieielmngfddkiiidnhcaaaaogadlpdifnpjaepip.mip
          --การจัดการแบบสอบถามรหัสผ่าน
          --management-ถือ
          --script-security2
          --route-up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
          --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
2022-04-30 06:24:40.108790 การจัดการ: ไคลเอนต์ที่เชื่อมต่อจาก [AF_INET]127.0.0.1:52399
2022-04-30 06:24:40.136505 การจัดการ: CMD 'pid'
2022-04-30 06:24:40.136565 การจัดการ: CMD 'โต้ตอบการลองตรวจสอบสิทธิ์อีกครั้ง'
2022-04-30 06:24:40.136595 การจัดการ: CMD 'สถานะเปิด'
2022-04-30 06:24:40.136615 การจัดการ: CMD 'สถานะ'
2022-04-30 06:24:40.136655 การจัดการ: CMD 'bytecount 1'
2022-04-30 06:24:40.138068 *Tunnelblick: สร้างการสื่อสารกับ OpenVPN
2022-04-30 06:24:40.152091 *Tunnelblick: >INFO:OpenVPN Management Interface เวอร์ชัน 1 -- พิมพ์ 'help' เพื่อดูข้อมูลเพิ่มเติม
2022-04-30 06:24:40.154175 การจัดการ: CMD 'ระงับการปล่อย'
2022-04-30 06:24:40.155529 หมายเหตุ: การตั้งค่า --script-security ปัจจุบันอาจอนุญาตให้การกำหนดค่านี้เรียกสคริปต์ที่ผู้ใช้กำหนด
2022-04-30 06:24:40.161486 การรับรองความถูกต้องของช่องควบคุมขาออก: การใช้แฮชข้อความ 160 บิต 'SHA1' สำหรับการตรวจสอบสิทธิ์ HMAC
2022-04-30 06:24:40.161545 การรับรองความถูกต้องของช่องควบคุมขาเข้า: การใช้แฮชข้อความ 160 บิต 'SHA1' สำหรับการตรวจสอบสิทธิ์ HMAC
2022-04-30 06:24:40.161718 การจัดการ: >STATE:1651292680,RESOLVE,,,,,,
2022-04-30 06:24:40.259123 TCP/UDP: การรักษาที่อยู่ระยะไกลที่ใช้ล่าสุด: [AF_INET]xx.xx.xx.xx:1194
2022-04-30 06:24:40.259272 บัฟเฟอร์ซ็อกเก็ต: R=[786896->786896] S=[9216->9216]
2022-04-30 06:24:40.259296 ลิงก์ UDP ในพื้นที่: (ไม่ผูกมัด)
2022-04-30 06:24:40.259311 ระยะไกลลิงก์ UDP: [AF_INET]xx.xx.xx.xx:1194
2022-04-30 06:24:40.259354 การจัดการ: >STATE:1651292680,WAIT,,,,,,
2022-04-30 06:24:40.305386 การจัดการ: >STATE:1651292680,AUTH,,,,,,
2022-04-30 06:24:40.305631 TLS: แพ็กเก็ตเริ่มต้นจาก [AF_INET]xx.xx.xx.xx:1194, sid=06c4262e 884c5cdc
2022-04-30 06:24:40.369493 ยืนยันตกลง: ความลึก=1, CN=กรีนไฮฟ์
2022-04-30 06:24:40.370236 ยืนยัน KU ตกลง
2022-04-30 06:24:40.370275 การตรวจสอบการใช้คีย์เสริมของใบรับรอง
2022-04-30 06:24:40.370301 ++ ใบรับรองมี EKU (str) TLS Web Server Authentication คาดว่า TLS Web Server Authentication
2022-04-30 06:24:40.370323 ยืนยัน EKU ตกลง
2022-04-30 06:24:40.370346 ยืนยันตกลง: ความลึก=0, CN=VPN.greenhive.at
2022-04-30 06:24:40.439317 คำเตือน: 'link-mtu' ถูกใช้อย่างไม่สอดคล้องกัน, local='link-mtu 1541', remote='link-mtu 1542'
2022-04-30 06:24:40.439596 คำเตือน: 'comp-lzo' มีอยู่ในการกำหนดค่าระยะไกล แต่ไม่มีอยู่ในการกำหนดค่าในเครื่อง remote='comp-lzo'
2022-04-30 06:24:40.439767 ช่องควบคุม: TLSv1.3, การเข้ารหัส TLSv1.3 TLS_AES_256_GCM_SHA384, RSA 2048 บิต
2022-04-30 06:24:40.439834 [VPN.greenhive.at] การเชื่อมต่อเพียร์เริ่มต้นด้วย [AF_INET]xx.xx.xx.xx:1194
2022-04-30 06:24:41.558800 การจัดการ: >STATE:1651292681,GET_CONFIG,,,,,,
2022-04-30 06:24:41.559492 การควบคุมการส่ง [VPN.greenhive.at]: 'PUSH_REQUEST' (สถานะ=1)
2022-04-30 06:24:41.652600 PUSH: ได้รับข้อความควบคุม: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,comp-lzo no,route 172.17.0.0 255.255.255.0,route- เกตเวย์ 192.168.255.1, เครือข่ายย่อยโทโพโลยี, ping 10, ping-restart 60, ifconfig 192.168.255.2 255.255.255.0, peer-id 1, cipher AES-256-GCM'
2022-04-30 06:24:41.652921 OPTIONS IMPORT: แก้ไขตัวจับเวลาและ/หรือหมดเวลา
2022-04-30 06:24:41.652958 OPTIONS นำเข้า: การบีบอัด parms แก้ไข
2022-04-30 06:24:41.652985 นำเข้าตัวเลือก: --ifconfig/up ตัวเลือกที่แก้ไข
2022-04-30 06:24:41.653008 นำเข้าตัวเลือก: แก้ไขตัวเลือกเส้นทาง
2022-04-30 06:24:41.653030 OPTIONS IMPORT: แก้ไขตัวเลือกที่เกี่ยวข้องกับเส้นทาง
2022-04-30 06:24:41.653051 นำเข้าตัวเลือก: --ip-win32 และ/หรือ --dhcp-ตัวเลือกตัวเลือกที่แก้ไข
2022-04-30 06:24:41.653072 นำเข้าตัวเลือก: ชุด peer-id
2022-04-30 06:24:41.653094 OPTIONS IMPORT: ปรับ link_mtu เป็น 1624
2022-04-30 06:24:41.653115 OPTIONS IMPORT: data channel crypto option modified
2022-04-30 06:24:41.653139 ช่องข้อมูล: ใช้รหัสลับ 'AES-256-GCM'
2022-04-30 06:24:41.653816 ช่องข้อมูลขาออก: Cipher 'AES-256-GCM' เริ่มต้นด้วยคีย์ 256 บิต
2022-04-30 06:24:41.653851 ช่องข้อมูลขาเข้า: Cipher 'AES-256-GCM' เริ่มต้นด้วยคีย์ 256 บิต
2022-04-30 06:24:41.654722 กำลังเปิด utun (เชื่อมต่อ(AF_SYS_CONTROL)): ทรัพยากรไม่ว่าง (errno=16)
2022-04-30 06:24:41.654977 กำลังเปิด utun (เชื่อมต่อ(AF_SYS_CONTROL)): ทรัพยากรไม่ว่าง (errno=16)
2022-04-30 06:24:41.655036 กำลังเปิด utun (เชื่อมต่อ(AF_SYS_CONTROL)): ทรัพยากรไม่ว่าง (errno=16)
2022-04-30 06:24:41.655181 เปิดอุปกรณ์ utun utun3
2022-04-30 06:24:41.655203 การจัดการ: >STATE:1651292681,ASSIGN_IP,,192.168.255.2,,,,
2022-04-30 06:24:41.655217 /sbin/ifconfig utun3 ลบ
                           ifconfig: ioctl (SIOCDIFADDR): ไม่สามารถกำหนดที่อยู่ที่ร้องขอได้
2022-04-30 06:24:41.665109 หมายเหตุ: พยายามลบอินสแตนซ์ tun/tap ที่มีอยู่แล้ว -- ไม่มีปัญหาหากล้มเหลว
2022-04-30 06:24:41.666818 /sbin/ifconfig utun3 192.168.255.2 192.168.255.2 netmask 255.255.255.0 mtu 1500 ขึ้นไป
2022-04-30 06:24:41.672645 /sbin/เส้นทาง เพิ่ม -net 192.168.255.0 192.168.255.2 255.255.255.0
                           เพิ่มสุทธิ 192.168.255.0: เกตเวย์ 192.168.255.2
2022-04-30 06:24:41.679237 การจัดการ: >STATE:1651292681,ADD_ROUTES,,,,,,
2022-04-30 06:24:41.679318 /sbin/เส้นทาง เพิ่ม -net 172.17.0.0 192.168.255.1 255.255.255.0
                           เพิ่มสุทธิ 172.17.0.0: เกตเวย์ 192.168.255.1
                           06:24:41 *Tunnelblick: ****************************************** ****
                           06:24:41 *Tunnelblick: เริ่มต้นเอาต์พุตจาก client.up.tunnelblick.sh
                           06:24:43 *Tunnelblick: ดึงมาจาก OpenVPN: เซิร์ฟเวอร์ชื่อ [ 8.8.8.8 8.8.4.4 ], โดเมนการค้นหา [ ] และเซิร์ฟเวอร์ SMB [ ] และใช้ชื่อโดเมนเริ่มต้น [ openvpn ]
                           06:24:44 *Tunnelblick: คำเตือน: ละเว้นชื่อโดเมน 'openvpn' เนื่องจากชื่อโดเมนถูกตั้งค่าด้วยตนเองและไม่ได้ระบุ '-allowChangesToManuallySetNetworkSettings'
                           06:24:44 * Tunnelblick: คำเตือน: ละเว้น ServerAddresses '8.8.8.8 8.8.4.4' เนื่องจาก ServerAddresses ถูกตั้งค่าด้วยตนเองและไม่ได้ระบุ '-allowChangesToManuallySetNetworkSettings'
                           06:24:44 *Tunnelblick: การตั้งค่าโดเมนการค้นหาเป็น '8.8.8.8 8.8.4.4' เนื่องจากไม่ได้ตั้งค่าโดเมนการค้นหาด้วยตนเอง (หรืออนุญาตให้เปลี่ยนได้) และไม่ได้เลือก 'เพิ่มชื่อโดเมนล่วงหน้าเป็นโดเมนการค้นหา'
                           06:24:45 *Tunnelblick: บันทึกการกำหนดค่า DNS และ SMB เพื่อให้สามารถกู้คืนได้
                           06:24:45 *Tunnelblick: ไม่ได้เปลี่ยนการตั้งค่า DNS ServerAddresses ของ '8.8.8.8 8.8.4.4' (แต่ตั้งค่าใหม่)
                           06:24:45 *Tunnelblick: เปลี่ยนการตั้งค่า DNS SearchDomains จาก 'openvpn' เป็น '8.8.8.8 8.8.4.4'
                           06:24:45 *Tunnelblick: เปลี่ยนการตั้งค่า DNS DomainName จาก '' เป็น '8.8.8.8 8.8.4.4'
                           06:24:45 *Tunnelblick: ไม่ได้เปลี่ยนการตั้งค่า SMB NetBIOSName ของ ''
                           06:24:45 *Tunnelblick: ไม่ได้เปลี่ยนการตั้งค่า SMB Workgroup ของ ''
                           06:24:45 *Tunnelblick: ไม่ได้เปลี่ยนการตั้งค่า SMB WINSAddresses ของ ''
                           06:24:45 *Tunnelblick: เซิร์ฟเวอร์ DNS '8.8.8.8 8.8.4.4' ถูกตั้งค่าด้วยตนเอง
                           06:24:45 *Tunnelblick: เซิร์ฟเวอร์ DNS '8.8.8.8 8.8.4.4' จะถูกใช้สำหรับการสืบค้น DNS เมื่อ VPN เปิดใช้งาน
                           06:24:45 *Tunnelblick: เซิร์ฟเวอร์ DNS รวมเฉพาะเซิร์ฟเวอร์ DNS สาธารณะฟรีที่ Tunnelblick รู้จัก
                           06:24:45 *Tunnelblick: ล้างแคช DNS ผ่าน dscacheutil
                           06:24:45 *Tunnelblick: /usr/sbin/discoveryutil ไม่มีอยู่ ไม่ล้างแคช DNS ผ่าน Discoveryutil
                           06:24:45 *Tunnelblick: แจ้ง mDNSResponder ว่าแคช DNS ถูกล้าง
                           06:24:45 *Tunnelblick: ไม่แจ้ง mDNSResponderHelper ว่าแคช DNS ถูกล้างเนื่องจากไม่ได้ทำงานอยู่
                           06:24:45 *Tunnelblick: การตั้งค่าเพื่อตรวจสอบการกำหนดค่าระบบด้วยกระบวนการ-เครือข่าย-การเปลี่ยนแปลง
                           06:24:45 *Tunnelblick: สิ้นสุดเอาต์พุตจาก client.up.tunnelblick.sh
                           06:24:45 *Tunnelblick: ****************************************** ****
2022-04-30 06:24:45.352811 คำเตือน: การกำหนดค่านี้อาจแคชรหัสผ่านในหน่วยความจำ -- ใช้ตัวเลือก auth-nocache เพื่อป้องกันสิ่งนี้
2022-04-30 06:24:45.352830 ลำดับการเริ่มต้นเสร็จสมบูรณ์
2022-04-30 06:24:45.352845 การจัดการ: >STATE:1651292685,CONNECTED,SUCCESS,192.168.255.2,xx.xx.xx.xx,1194,,
2022-04-30 06:24:46.571157 *Tunnelblick: ข้อมูลเส้นทาง stdout:
   เส้นทางไปที่: 8.8.4.4
ปลายทาง: 8.8.4.4
    เกตเวย์: 192.168.88.1
  อินเทอร์เฟซ: en0
      ค่าสถานะ: <UP,GATEWAY,HOST,DONE,WACLONED,IFSCOPE,IFREF,GLOBAL>
 recvpipe sendpipe ssthresh rtt, msec rttvar hopcount mtu หมดอายุ
       0 0 0 0 0 0 1500 0 
สเตเดอร์:

2022-04-30 06:24:46.593014 *Tunnelblick: คำเตือน: ที่อยู่เซิร์ฟเวอร์ DNS 8.8.4.4 เป็นเซิร์ฟเวอร์ DNS สาธารณะที่รู้จัก แต่ไม่ถูกกำหนดเส้นทางผ่าน VPN
2022-04-30 06:24:46.680197 *Tunnelblick: ข้อมูลเส้นทาง stdout:
   เส้นทางไปที่: 8.8.8.8
ปลายทาง: 8.8.8.8
    เกตเวย์: 192.168.88.1
  อินเทอร์เฟซ: en0
      ค่าสถานะ: <UP,GATEWAY,HOST,DONE,WACLONED,IFSCOPE,IFREF,GLOBAL>
 recvpipe sendpipe ssthresh rtt, msec rttvar hopcount mtu หมดอายุ
       0 0 0 0 0 0 1500 0 
สเตเดอร์:

2022-04-30 06:24:46.705581 *Tunnelblick: คำเตือน: ที่อยู่เซิร์ฟเวอร์ DNS 8.8.8.8 เป็นเซิร์ฟเวอร์ DNS สาธารณะที่รู้จัก แต่ไม่ถูกกำหนดเส้นทางผ่าน VPN

แก้ไข: นี่คือเส้นทาง ip ของเซิร์ฟเวอร์

bash-5.0# เส้นทาง ip 
ค่าเริ่มต้นผ่าน 172.17.0.1 dev eth0 
10.0.0.0/24 ผ่าน 192.168.255.2 พัฒนา tun0 
10.0.1.0/24 ผ่าน 192.168.255.2 dev tun0 
10.0.3.0/24 ผ่าน 192.168.255.2 พัฒนา tun0 
172.17.0.0/16 dev eth0 proto kernel ขอบเขตลิงค์ src 
172.17.0.2 192.168.254.0/24 ผ่าน 192.168.255.2 dev tun0 192.168.255.0/24 dev tun0 proto kernel scope link src 192.168.255.1

ของลูกค้า

172.17/24 192.168.255.2 UGSc utun3

บันทึกสถานะ

bash-5.0# cat /tmp/openvpn-status.log
รายชื่อลูกค้า OpenVPN
อัปเดตเมื่อวันอาทิตย์ที่ 1 พฤษภาคม 08:20:48 น. 2565
ชื่อสามัญ, ที่อยู่จริง, ไบต์ที่ได้รับ, ไบต์ที่ส่ง, เชื่อมต่อตั้งแต่
at_dev_1,179.115.236.15:34846,23335,23021,อาทิตย์ 1 พฤษภาคม 07:14:26 2022
master,179.115.236.15:64773,9574,9889,อาทิตย์ 1 พฤษภาคม 07:55:44 2022
ตารางเส้นทาง
ที่อยู่เสมือน, ชื่อสามัญ, ที่อยู่จริง, การอ้างอิงล่าสุด
192.168.255.2,มาสเตอร์,179.115.236.15:64773,อา. 1 พฤษภาคม 07:55:44 น. 2565
10.0.0.1,at_dev_1,179.115.236.15:34846,อาทิตย์ 1 พฤษภาคม 07:14:26 2022
สถิติทั่วโลก
ความยาวคิว bcast/mcast สูงสุด1
จบ

แก้ไขรูปภาพที่นี่เพื่อแสดงสถานการณ์ คำอธิบายกราฟิก

Nikita Kipriyanov avatar
za flag
โปรดแสดงเอาต์พุต "เส้นทาง ip" ของระบบที่ได้รับผลกระทบเมื่อสร้างการเชื่อมต่อ VPN และเอาต์พุตของคำสั่ง "สถานะ" ในอินเทอร์เฟซการจัดการ OpenVPN (เพื่อแสดงเส้นทางภายในและสถานะอื่นๆ) คุณสามารถปกปิด IP สาธารณะได้ แต่คงที่อยู่ส่วนตัวทั้งหมดไว้ตามเดิม ฉันต้องการทราบด้วยว่า `โทโพโลยี' ไม่มีส่วนเกี่ยวข้องกับวิธีที่คุณจัดวางเครือข่ายนอก OpenVPN มันตั้งค่าการทำงานภายในเท่านั้น โหมด `ทอพอโลยีซับเน็ต' ทำให้ OpenVPN เป็นเราเตอร์และต้องตั้งค่าเส้นทาง *ภายใน* ด้วยความช่วยเหลือของคำสั่ง 'iroute' ที่เข้าไปในไฟล์ CCD
Nikita Kipriyanov avatar
za flag
โปรดใส่เอาต์พุตการกำหนดเส้นทางของคุณลงในคำถามโดย[แก้ไข](https://serverfault.com/posts/1099885/edit) และลบออกจากความคิดเห็น มันขึ้นบรรทัดใหม่ในความคิดเห็นดังนั้นจึงไม่สามารถอ่านได้ นอกจากนี้ฉันยังถามผลลัพธ์ * การจัดการ * `สถานะ' มันแสดงให้เห็นภายในที่เราต้องการที่นี่ เป็นสิ่งสำคัญในโหมด `subnet` เนื่องจากจะแสดงตารางเส้นทางภายในกระบวนการ OpenVPN เอง // แจ้งให้ทราบ ฉันได้พูดคุยเกี่ยวกับ `iroute` ไม่เกี่ยวกับ push route และอื่น ๆอ่าน `man openvpn` เกี่ยวกับคำสั่งนั้นและสิ่งที่ทำ
Robert Driller avatar
cn flag
ขอโทษด้วย ฉันปรับมันแล้ว ฉันยังได้อ่านเพิ่มเติมเกี่ยวกับเส้นทาง โปรดแก้ไขฉันหากฉันผิด แต่ฉันเข้าใจว่าเป็นการกำหนดเส้นทางพิเศษในกรณีที่ฉันต้องการเชื่อมต่อกับที่อยู่ที่ "เข้าถึงได้" ผ่านทาง VPN **ไคลเอนต์** แต่เนื่องจากที่อยู่ที่ฉันต้องการติดต่อนั้นอยู่ใน LAN ของ VPN **เซิร์ฟเวอร์** และฉันต้องการให้ไคลเอ็นต์ทั้งหมดสามารถติดต่อได้ การพุชรูทไม่ใช่วิธีที่ถูกต้องใช่ไหม ฉันได้รับสิ่งนี้จาก https://backreference.org/2009/11/15/openvpn-and-iroute/index.html
Nikita Kipriyanov avatar
za flag
ใช่ ฉันกำลังเขียนคำตอบพร้อมคำอธิบาย มันไม่ได้ "ซ่อนอยู่หลังไคลเอนต์" แต่เป็นการกำหนดเส้นทางที่เกิดขึ้นภายในกระบวนการ OpenVPN บนเซิร์ฟเวอร์
Score:0
ธง za

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

โครงสร้างทั่วไปของ OpenVPN "topology subnet" VPN มีลักษณะเช่นนี้จากมุมมองของเครือข่าย (OSI L3):

                                          192.168.255.10[tun] (client2) [eth] 10.0.2.1 --- ...
                                                   |
                                              [client2].9 [th] 10.0.1.1 --- ...
(เซิร์ฟเวอร์) [tun]192.168.255.1 --- .2[เซิร์ฟเวอร์] (กระบวนการ OpenVPN) [client1].5 --- 192.168.255.6[tun] (client1)
[eth] 10.0.0.1 --- ... .13[client3]
                                                   |
         ... --- 10.0.3.1 [eth] (client3) [tun]192.168.255.14

ในตัวอย่างนี้ที่มีไคลเอนต์สามเครื่อง กระบวนการ OpenVPN จะดูเหมือนเราเตอร์ที่มีสี่อินเทอร์เฟซ (อันหนึ่งหันไปทางเซิร์ฟเวอร์) เราเตอร์นี้จำเป็นต้องตั้งค่าการกำหนดเส้นทางด้วย! นี่คืออะไร เส้นทาง คำหลักไม่

เพื่อให้ลูกค้าเข้าถึงเครือข่าย 10.0.0.0/24 หลังเซิร์ฟเวอร์ พวกเขาต้องการเส้นทางไปยังเครือข่ายนั้นผ่าน "ที่อยู่" ที่ติดต่อกับไคลเอนต์ OpenVPN ตามลำดับ (ตัวอย่างเช่น ลูกค้า 1 ต้องการ เส้นทาง ip เพิ่ม 10.0.0.0/24 ผ่าน 192.168.255.5). เส้นทางเหล่านี้คุณผลักดันด้วย "เส้นทางผลักดัน" ในการเข้าถึงเครือข่ายที่อยู่เบื้องหลังไคลเอนต์อื่น คุณต้องสร้างเส้นทางที่คล้ายกัน ในกรณีตัวอย่างของฉัน เครือข่ายเหล่านี้ติดต่อกันและเครือข่ายทั้งหมดสามารถรวมเป็นเครือข่ายเดียวได้ กด "เส้นทาง 10.0.0.0 255.255.252.0".

นอกจากนี้ "เราเตอร์" ของ OpenVPN ยังต้องการเส้นทางที่เหมาะสมไปยังเครือข่ายเหล่านี้ผ่านที่อยู่ "ไคลเอ็นต์" ตัวอย่างเช่น เครือข่าย 10.0.1.0/24 ควรกำหนดเส้นทางผ่าน 192.168.255.6 ในการดำเนินการดังกล่าว เซิร์ฟเวอร์จำเป็นต้องเรียกใช้ เส้นทาง 10.0.1.0 255.255.255.0 เป็นตัวแทนของ ลูกค้า1. เพื่อให้บรรลุสิ่งนี้คุณใส่

เส้นทาง 10.0.1.0 255.255.255.0

เข้าไปข้างใน ลูกค้า1 ไฟล์ในไดเร็กทอรีการกำหนดค่าไคลเอนต์ (CCD) ดังนั้นจึงได้รับการดำเนินการทันทีหลังจากไคลเอนต์ที่มีชื่อสามัญ ลูกค้า1 ตรวจสอบสิทธิ์สำเร็จ

ไม่จำเป็นต้องใช้เครือข่ายที่อยู่หลังเซิร์ฟเวอร์ เส้นทาง. ดูเหมือนว่าจะใช้ "อินเทอร์เฟซ" ของเซิร์ฟเวอร์เป็นเกตเวย์ของทางเลือกสุดท้าย

Robert Driller avatar
cn flag
ขอบคุณมากสำหรับคำตอบโดยละเอียดเพื่อให้แน่ใจว่าฉันเข้าใจถูกต้อง ข้อมูลการกำหนดเส้นทางในฝั่งไคลเอนต์ผ่านเส้นทางพุชไม่เพียงพอ เซิร์ฟเวอร์ต้องการการกำหนดเส้นทางด้วยโดยใช้ iroute โดยตรงในการกำหนดค่าเซิร์ฟเวอร์ ฉันเพิ่ม iroute แบบนี้ `iroute 172.17.0.0 255.255.255.0` ในการกำหนดค่าเซิร์ฟเวอร์ แต่เมื่อเปิด openVPN มันบอกฉันว่า: `Options error: option 'iroute' can be used in this context (/etc/openvpn/ openvpn.conf) ใช้ --help สำหรับข้อมูลเพิ่มเติม` ฉันเข้าใจย่อหน้าที่แล้วของคุณผิดไปหรือเปล่า?
Nikita Kipriyanov avatar
za flag
ใช่เพราะมันผิด มันเตือนฉันว่าฉันควรอ่านคู่มือซ้ำเสมอ แม้ว่าฉันจะอ่านหลายครั้งแล้วก็ตาม ดูเหมือนว่าเส้นทางผ่านเซิร์ฟเวอร์โดยค่าเริ่มต้น เช่น มันใช้เซิร์ฟเวอร์เป็นเกตเวย์ของทางเลือกสุดท้าย สิ่งนี้จะอธิบายได้ว่าทำไมเครือข่ายย่อยของเซิร์ฟเวอร์จึงไม่ต้องการการวนซ้ำ สิ่งที่เกี่ยวกับปัญหาเดิมของคุณคือคุณให้ที่อยู่ไคลเอนต์ของคุณซึ่งเข้ากันไม่ได้กับเครือข่าย VPN ด้วยวิธีใดวิธีหนึ่ง เครือข่ายย่อยคือ /30 เครือข่ายที่แกะสลักจากพื้นที่ที่อยู่ VPN; หากคุณเลือก `192.168.255.1 255.255.255.0" เป็น IP ของเซิร์ฟเวอร์ ลูกค้าของคุณจะมี 192.168.255.6/30, .10, .14 ฯลฯ ที่กำหนดให้กับอินเทอร์เฟซ `tun`
Robert Driller avatar
cn flag
ขอโทษที่คุณทำฉันหายไปที่นั่น ฉันเข้าใจว่าแต่ละเครือข่ายย่อยของฉัน (10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24 เป็นต้น) มีอินเทอร์เฟซ tun ที่กำหนดด้วยช่องว่าง /30 นั่นหมายความว่ามีเพียง 127 ซับเน็ตที่เป็นไปได้เนื่องจากแต่ละรายการสงวน 2 ที่อยู่หรือไม่ และถ้าการสื่อสารทั้งหมดถูกกำหนดเส้นทางผ่านเซิร์ฟเวอร์ เหตุใดจึงไม่กำหนดเส้นทางการโทรของฉันไปยังที่อยู่ 172.14.0.4 ที่อยู่ด้านหลังเซิร์ฟเวอร์ oVPN

โพสต์คำตอบ

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