การเชื่อมต่อกับเซิร์ฟเวอร์ระยะไกลผ่าน VPN เมื่อที่อยู่เครือข่ายย่อยในเครือข่ายท้องถิ่นขัดแย้งกับเครือข่ายระยะไกล

นี่เป็นคำถามที่ยอมรับได้ของ Canonicalเกี่ยวกับการแก้ไขข้อขัดแย้งของซับเน็ต IPv4 ระหว่างเครือข่ายท้องถิ่นของไคลเอนต์ VPN และอีกอันหนึ่งผ่านการเชื่อมโยง VPN จากมัน

หลังจากเชื่อมต่อไปยังสถานที่ห่างไกลผ่าน OpenVPN ลูกค้าจะพยายามเข้าถึงเซิร์ฟเวอร์บนเครือข่ายที่มีอยู่ในเครือข่ายย่อยเช่น 192.0.2.0/24 อย่างไรก็ตามบางครั้งเครือข่ายบน LAN ของไคลเอ็นต์มีที่อยู่เครือข่ายย่อยเดียวกัน: 192.0.2.0/24 ลูกค้าไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ระยะไกลผ่านการพิมพ์ใน IP ของมันเนื่องจากความขัดแย้งนี้ พวกเขาไม่สามารถแม้แต่จะเข้าถึงอินเทอร์เน็ตสาธารณะในขณะที่เชื่อมต่อกับ VPN

ปัญหาคือว่าซับเน็ต 192.0.2.0/24 นี้จำเป็นต้องกำหนดเส้นทางโดย VPN แต่ก็จำเป็นต้องกำหนดเส้นทางเป็น LAN ของไคลเอ็นต์ด้วย

ไม่มีใครรู้วิธีบรรเทาปัญหานี้หรือไม่? ฉันสามารถเข้าถึงเซิร์ฟเวอร์ OpenVPN

เป็นไปได้ที่จะแก้ปัญหานี้โดยใช้ NAT; มันไม่หรูหรามาก

ดังนั้นภายใต้สมมติฐานที่ว่าคุณไม่สามารถแก้ปัญหานี้ได้โดยการมีเครือข่ายภายในซึ่งมีหมายเลขเครือข่ายที่ไม่ธรรมดาซึ่งไม่เคยขัดแย้งกันจริงนี่คือหลักการ:

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

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

ทำอวนขึ้นที่นี่:

• เครือข่ายสำนักงานของคุณใช้ 192.0.2.0/24
• สำนักงานระยะไกลของคุณใช้ 192.0.2.0/24
• เกตเวย์ VPN เครือข่ายสำนักงานของคุณซ่อนโฮสต์ 192.0.2.0/24 ไว้เบื้องหลังหมายเลขเครือข่าย NATed 198.51.100.0/24
• เกตเวย์ VPN เครือข่ายสำนักงานระยะไกลของคุณซ่อน 192.0.2.0/24 โฮสต์ที่อยู่เบื้องหลังหมายเลขเครือข่าย NATed 203.0.113.0/24

ดังนั้นภายในอุโมงค์ VPN โฮสต์ของสำนักงานในปัจจุบันคือ 198.51.100.x และโฮสต์ของสำนักงานระยะไกลคือ 203.0.113.x สมมติว่าโฮสต์ทั้งหมดถูกแมป 1: 1 ใน NAT ของเกตเวย์ VPN ที่เกี่ยวข้อง ตัวอย่าง:

• โฮสต์เครือข่ายสำนักงานของคุณ 192.0.2.5/24 ถูกแมปแบบคงที่เป็น 198.51.100.5/24 ในเกตเวย์ vpn สำนักงาน NAT
• โฮสต์เครือข่ายสำนักงานระยะไกลของคุณ 192.0.2.5/24 ถูกแมปแบบคงที่เป็น 203.0.113.5/24 ในเกตเวย์ vpn สำนักงานระยะไกล NAT

ดังนั้นเมื่อโฮสต์ 192.0.2.5/24 ในสำนักงานระยะไกลต้องการที่จะเชื่อมต่อกับโฮสต์ที่มี IP เดียวกันในเครือข่ายสำนักงานก็ต้องทำเช่นนั้นโดยใช้ที่อยู่ 198.51.100.5/24 เป็นปลายทาง สิ่งต่อไปนี้เกิดขึ้น:

• ที่สำนักงานระยะไกลโฮสต์ 198.51.100.5 เป็นปลายทางระยะไกลที่เข้าถึงผ่าน VPN และส่งไปที่นั่น
• ที่สำนักงานระยะไกลโฮสต์ 192.0.2.5 ถูกปลอมแปลงเป็น 203.0.113.5 เมื่อแพ็กเก็ตส่งผ่านฟังก์ชัน NAT
• ที่สำนักงานโฮสต์ 198.51.100.5 ถูกแปลเป็น 192.0.2.5 เมื่อแพ็กเก็ตส่งผ่านฟังก์ชัน NAT
• ที่สำนักงานให้ส่งคืนทราฟฟิกไปยังโฮสต์ 203.0.113.5 ผ่านกระบวนการเดียวกันในทิศทางตรงกันข้าม

ดังนั้นในขณะที่มีวิธีแก้ปัญหามีหลายประเด็นที่ต้องแก้ไขเพื่อให้สามารถใช้งานได้จริง:

• IP ปลอมตัวจะต้องใช้สำหรับการเชื่อมต่อระยะไกล DNS มีความซับซ้อน นี่เป็นเพราะปลายทางต้องมีที่อยู่ IP ที่ไม่ซ้ำกันตามที่ดูจากโฮสต์ที่เชื่อมต่อ
• ฟังก์ชัน NAT จะต้องใช้งานทั้งสองด้านซึ่งเป็นส่วนหนึ่งของโซลูชัน VPN
• โฮสต์การแมปแบบคงที่เป็นสิ่งจำเป็นสำหรับการเข้าถึงจากปลายอีกด้าน
• หากการรับส่งข้อมูลเป็นแบบทิศทางเดียวปลายทางที่ได้รับเท่านั้นที่ต้องการการจับคู่แบบคงที่ของโฮสต์ที่เกี่ยวข้องทั้งหมด ลูกค้าสามารถออกไปด้วยการเป็น NATed แบบไดนามิกหากต้องการ
• หากการรับส่งข้อมูลเป็นแบบสองทิศทางปลายทั้งสองด้านจำเป็นต้องทำการแมปแบบคงที่ของโฮสต์ที่เกี่ยวข้องทั้งหมด
• การเชื่อมต่ออินเทอร์เน็ตจะต้องไม่ถูกทำให้เสียหายโดยไม่คำนึงถึง VPN แบบแยกหรือไม่แยก
• หากคุณไม่สามารถแมป 1 ต่อ 1 มันจะเลอะเทอะ การทำบัญชีอย่างระมัดระวังเป็นสิ่งจำเป็น
• โดยปกติแล้วหนึ่งความเสี่ยงของการใช้ที่อยู่ NAT ซึ่งกลายเป็นซ้ำ :-)

ดังนั้นการแก้ปัญหานี้จำเป็นต้องมีการออกแบบอย่างระมัดระวัง หากสำนักงานระยะไกลของคุณประกอบด้วยนักรบถนนจริง ๆ คุณเพิ่มปัญหาหลายอย่างในนั้น:

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

ขึ้นอยู่กับไคลเอนต์ VPN ของคุณคุณอาจเลือกหนึ่ง VPN โดยอัตโนมัติหรืออื่น ๆ ขึ้นอยู่กับที่อยู่เครือข่ายของกลุ่มโลคัล

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

ซึ่งหมายความว่าจะต้องไม่สับสนกับที่อยู่ IP สาธารณะของเกตเวย์ VPN (และในทางปฏิบัติอาจเป็น NAT: ed แต่จากนั้นทั้งหมดนอกมุมมองของการขนส่งไปยังไซต์ระยะไกลผ่าน VPN) ด้วยที่อยู่ส่วนตัวที่ไม่ซ้ำกัน สำหรับที่อยู่ส่วนตัวที่ซ้ำกัน หากนามธรรมนี้เป็นเรื่องยากที่จะภาพ, การสาธิตวิธี NAT อาจจะแยกทางร่างกายจาก VPN เกตเวย์เพื่อวัตถุประสงค์นี้จะทำที่นี่:
ใช้ NAT ในเครือข่ายที่ทับซ้อนกัน

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

ให้ความมั่นใจว่าจะเป็นไปได้อย่างแน่นอน:
PIX / ASA 7.x และใหม่กว่า: LAN-to-IP IPsec VPN พร้อมตัวอย่างการกำหนดค่าเครือข่ายที่ทับซ้อนกัน
และ: การ
กำหนดค่าอุโมงค์ IPSec ระหว่างเราเตอร์ที่มีเครือข่ายย่อย LAN ซ้ำ

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

ฉันเรียนรู้สิ่งนี้จาก Cisco เมื่อเห็นลิงก์

หากคุณต้องการวิธีแก้ปัญหาชั่วคราวที่สกปรกไปยังเซิร์ฟเวอร์ ips เดี่ยวหรือเซิร์ฟเวอร์ที่รู้จักจำนวนน้อยโซลูชันที่ง่ายที่สุดควรเป็นตัวเลือกการจัดเส้นทางด้านไคลเอนต์แบบคงที่

ในกรณีของฉันฉันเพิ่มเซิร์ฟเวอร์ปลายทางที่ต้องการ (192.168.1.100) ลงในตารางเส้นทางของฉันบนไคลเอนต์ linux ของฉันผ่าน:

route add 192.168.1.100 dev tun0

หลังจากนั้นให้ลบเส้นทางแบบคงที่นี้ด้วยคำสั่ง route delete

ใช่นี่มันแย่ที่สุด สำหรับฉันมันเกิดขึ้นตลอดเวลาจากห้องพักในโรงแรมก่อนที่ผู้ดูแลระบบ vpn จะตระหนักว่าพวกเขาควรใช้ช่วง ip ที่ไม่ชัดเจนมากขึ้น 10.0.0.0/24 และ 10.1.1.1/24 นั้นแย่ที่สุด หากคุณสามารถช่วยได้มันจะไม่เป็นเครือข่ายไร้สายแบบนั้น

ดังนั้นคำตอบคือ "แก้ไข" WAP เพื่อใช้เครือข่ายภายในที่แตกต่างกัน (เช่น 10.255.255.0/24) แล้วให้สัญญาเช่าต่าง (เช่น IP ในช่วงที่สามารถกำหนดเส้นทางกลับไปที่ corp vpn) หรือถ้าคุณไม่มี / ไม่สามารถจัดการ admin บน WAP เพียงไปที่ starbucks หรือ 20 นาทีของการขับไล่ :)

หากนี่เป็นเพียงในการตั้งค่าห้องปฏิบัติการเพียงใช้ช่วงที่แตกต่างกัน

ฉันใช้ Mac ที่ทำงาน El Capitan ในขณะที่คำแนะนำข้างต้นไม่ได้ผลสำหรับฉันพวกเขานำฉันไปสู่โซลูชันที่ใช้งานได้:

1. ก่อนเริ่ม VPN ให้ดำเนินการ ifconfig

2. เริ่มต้น VPN ทำifconfigและสังเกตว่าเป็นอินเทอร์เฟซใหม่ ในกรณีของฉันมันเป็นppp0 ที่มีที่อยู่ ip ของ192.168.42.74

   ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
       inet 192.168.42.74 --> 192.0.2.1 netmask 0xffffff00
   

3. พิมพ์ใน:

   sudo route add 192.168.1.79  192.168.42.74
   

ฉันทดสอบก่อนด้วย a pingจากนั้นฉันพิสูจน์ว่ามันทำงานได้โดยการเข้าถึงเซิร์ฟเวอร์ git

เมื่อฉันลองใช้dev ppp0ในตอนท้ายของคำสั่งเส้นทางดังกล่าวข้างต้นก็บ่น

ฉันมีวิธีง่ายๆที่ฉันใช้ในพื้นที่ทำงานร่วมที่มีช่วง IP ที่ขัดแย้งกัน (10.x)

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

ฉันแน่ใจว่าจะใช้งานได้เหมือนกันผ่าน USB หากคุณต้องการการเชื่อมต่อที่เร็วขึ้น

หากคุณต้องการที่อยู่ IP หนึ่งหรือสองรายการให้เพิ่มคำสั่งเส้นทางไปยังไฟล์กำหนดค่า ovpn ดังนี้:

เส้นทาง 192.168.1.10 255.255.255.255

เส้นทาง 192.168.1.11 255.255.255.255

มันจะเพิ่มเส้นทางสำหรับไอพีเหล่านั้นเมื่อคุณเชื่อมต่อ VPN ของคุณและลบมันเมื่อ VPN ตัดการเชื่อมต่อ

ทำงานให้ฉันบน Windows ต่อไป

คำตอบจาก Aydin K. สำหรับ linux หากคุณต้องการ funtionality เดียวกันสำหรับ windows คุณสามารถพิมพ์

route ADD 192.168.1.10 <IP of tunnel adapter>

หรือ

route ADD 192.168.1.10 IF <interface id>

คุณสามารถรับรหัสอินเทอร์เฟซด้วยคำสั่ง:

route print

เช่นเดียวกับการเตือน: ปัญหาทั้งหมดนี้เกิดจากการขาดแคลนที่อยู่ IPv4 เป็นเวลาหลายปีและการใช้ช่วง IP ส่วนตัวอย่างกว้างขวางหลัง NAT เพื่อแก้ไขปัญหาการขาดแคลนนี้!

ทางออกที่ดีที่สุดและชัดเจนสำหรับปัญหานี้ค่อนข้างตรงไปตรงมา (แม้ว่าจะทำได้และจะต้องใช้เวลาพอสมควรในการเปิดตัวทั่วโลก): IPv6 ...

ในโลก IPv6 ไม่มีการขาดแคลน IP สาธารณะ (และจะไม่มีในอีกไม่กี่ทศวรรษ) ดังนั้นจึงไม่มีเหตุผลที่จะไม่มี IP สาธารณะในแต่ละอุปกรณ์ของทุกเครือข่าย และถ้าคุณต้องการการแยกเครือข่ายให้กรองด้วยไฟร์วอลล์ แต่ไม่มี NAT น่าเกลียด ...