Score:0

ปัญหาเกี่ยวกับอุโมงค์ข้าม OpenVPN

ธง ke

ฉันมีโทโพโลยีเครือข่ายต่อไปนี้ ฉันอยู่ที่ VPN Client 1 ก่อนอื่นฉันสร้าง VPN Tunnel 1 และ VPN Client 1 เชื่อมต่อกับ VPN Server 2 ได้สำเร็จและสามารถพูดคุยกับ VPN Client 2 ซึ่งเชื่อมต่อกับ LAN เดียวกันกับ VPN Server 2

อย่างไรก็ตาม เมื่อฉันพยายามสร้าง VPN Tunnel 2 จาก VPN Client 2 ไปยัง VPN Server 1 (โดยมี SSH ผ่าน VPN Tunnel 1 ไปยัง VPN Client 2) ฉันสูญเสียการเชื่อมต่อกับ VPN Client 2 และไม่สามารถแม้แต่จะ ping ได้ (VPN อุโมงค์ที่ 1 ยังคงอยู่)ความคิดใดที่อาจผิดพลาดที่นี่?

อุโมงค์ VPN ทั้งหมดใช้งานโดยใช้เซิร์ฟเวอร์/ไคลเอนต์ OpenVPN

ขอบคุณมาก!

แผนภาพโทโพโลยี

dominix avatar
gf flag
คำอธิบายของคุณไม่ชัดเจน ลองใช้ "เครื่อง" สำหรับเครื่องและไคลเอนต์และเซิร์ฟเวอร์สำหรับบริการ openvpn เพื่อให้ทุกคนเข้าใจว่าเครื่องใดเชื่อมต่อกับเครื่องใดโดยใช้วิธีใด เป็นสิ่งสำคัญเนื่องจากเซิร์ฟเวอร์ openvpn เป็นเราเตอร์ด้วยตัวมันเองที่ขับเคลื่อนพฤติกรรมของลูกค้า
Cur10usMind avatar
ke flag
@dominix ฉันต้องการลดจำนวนคำที่ฉันใช้ให้น้อยที่สุด คำถามจะสมเหตุสมผลก็ต่อเมื่อคุณดูไดอะแกรมที่แนบมาด้วย
Score:0
ธง gf

นี่คือสิ่งที่เราได้รับ (รูปภาพของคุณจะไม่สามารถใช้งานได้ในเร็วๆ นี้)

           v-------<<--VPN2-------------v
[CLI1]---[SRV1]---{อินเทอร์เน็ต}---[SRV2]---[CLI2]
   ^------------VPN1->>-----------^

สิ่งที่คุณกำลังทำเมื่อสร้าง VPN ที่สองคือการตั้งค่าเส้นทางที่สองสำหรับลิงก์ CLI1 ไปยัง CLI2 เดียวกัน ดังนั้นเมื่อ CLI2 พยายามเข้าถึง CLI1 โดยใช้ VPN2 CLI1 จึงใช้ VPN1 เพื่อติดต่อกลับไปยัง CLI2 ดังนั้นฉันค่อนข้างแน่ใจว่าคุณมี NAT หรือ MASQUERADE บางอย่างที่ไม่อนุญาตให้ TCP สร้าง

เมื่อสร้าง VPN แรกของคุณแล้ว คุณควรใช้ VPN นี้เพื่อเดินทางกลับ ดังนั้น CLI2 จะเข้าถึง CLI1 โดยใช้เส้นทางที่ CLI1 รู้อยู่แล้วและจะใช้งานได้โดยทั่วไปคุณไม่สามารถสร้าง VPN2 ได้ แต่ให้เส้นทางกลับไปที่ CLI1 ของคุณที่ openvpn ที่ SVR2

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

[CLI1]---[SRV1]---{อินเทอร์เน็ต}---[SRV2]---[CLI2]
            ^-------VPN1->>-------^

โปรดทราบว่า openVPN เป็นสองสิ่ง 1/ ตัวจัดการอินเทอร์เฟซที่มี crypto ระหว่างอินเทอร์เฟซในพื้นที่และระยะไกล 2/ เราเตอร์ภายในเครื่องที่มักจะทำหน้าที่เป็นเราเตอร์ ดังนั้นคุณต้องกำหนดเส้นทางให้กับ SRV1 และ SRV2 ของคุณ และ ให้เส้นทางไปยังกระบวนการ openVPN ของคุณ => ดูที่ เส้นทาง และ ไคลเอ็นต์-config-dir ตัวเลือกใน openVPN;

[CLI1]---[SRV1]---{อินเทอร์เน็ต}---[SRV2]---[CLI2]
            ^ ^
        RouteToLAN2 เส้นทางกลับ ToLAN1
            ^-------VPN1->>-------^
Cur10usMind avatar
ke flag
ขอขอบคุณที่สละเวลาอธิบาย! อุโมงค์ VPN แบบสมมาตรระหว่างเราเตอร์สองตัวจะเป็นสถานการณ์ที่เหมาะสมที่สุด อย่างไรก็ตาม อุโมงค์เหล่านี้ไม่รองรับไคลเอนต์ VPN (เปิด) ดังนั้น ฉันต้องเรียกใช้ไคลเอนต์เหล่านี้บนอุปกรณ์อื่นใน LAN ที่เกี่ยวข้อง
Cur10usMind avatar
ke flag
ฉันยังสังเกตเห็นว่าด้วยเหตุผลบางอย่างอินเทอร์เฟซ OpenVPN tun0 บนไคลเอนต์ VPN 2 (เมื่อเชื่อมต่อกับเซิร์ฟเวอร์ VPN 1) ทำให้อินเทอร์เฟซ eth0 LAN หยุดทำงาน และเป็นผลให้การเชื่อมต่อเริ่มต้นระหว่างมันกับไคลเอ็นต์ VPN 1 จะลดลงฉันติดตั้ง OpenVPN ใหม่บนไคลเอนต์ VPN 2 และปัญหาได้รับการแก้ไขแล้ว ฉันยังไม่ถึงจุดต่ำสุดของมัน ฉันจะให้ข้อมูลอัปเดตเมื่อฉัน (หวังว่า) จะทำ!
dominix avatar
gf flag
ฉันไม่รู้ว่าทำไมคุณถึงพูดเช่นนั้น การสนับสนุนอย่างสมบูรณ์และเป็นธรรมชาติที่จะมีทั้งไคลเอนต์และเซิร์ฟเวอร์ในเครื่องเดียวกัน พยายามอธิบายว่าทำไมคุณถึงคิดว่าคุณทำไม่ได้ อย่างไรก็ตาม ในข้อเสนอของฉัน คุณเพียงแค่ต้องการหนึ่งเซิร์ฟเวอร์บน SRV2 และหนึ่งไคลเอ็นต์บน SRV1
dominix avatar
gf flag
โปรดแสดงตัวอย่าง openvpn config client2 ของคุณในโพสต์ต้นฉบับของคุณ ฉัน (หรือบางคน) สามารถชี้ให้เห็นถึงการกำหนดค่าที่ผิดพลาด
Cur10usMind avatar
ke flag
เราเตอร์ที่เซิร์ฟเวอร์ OpenVPN ทำงานอยู่ ไม่รองรับไคลเอนต์ VPN
dominix avatar
gf flag
เป็นไบนารีเดียวกับที่ทำหน้าที่เป็นเซิร์ฟเวอร์หรือไคลเอ็นต์ ดังนั้นคำว่า "สนับสนุน" ในที่นี้จึงไม่เหมาะสม ถ้ามันทำหน้าที่เป็นเซิร์ฟเวอร์ openvpn มันจะ _support_ openvpn ดังนั้นโดยการกำหนดค่า มันควรจะรองรับไคลเอนต์ openvpn เช่นกัน แสดงข้อผิดพลาดหรือการกำหนดค่าที่คุณใช้ และจะเห็น
Cur10usMind avatar
ke flag
น่าเสียดายที่เราเตอร์ที่บ้านที่ฉันใช้ไม่รองรับไคลเอนต์ OpenVPN ผ่านเมนูกำหนดค่า
dominix avatar
gf flag
ดังนั้นจึงไม่มีปัญหากับเส้นทางหรือ openVPN อีกต่อไป แต่เป็นปัญหาเกี่ยวกับความเข้าใจผิดเกี่ยวกับเราเตอร์ที่บ้านของคุณ คุณควรยอมรับคำตอบของฉันหรือลบคำถามของคุณ
Cur10usMind avatar
ke flag
ฉันคิดว่าคุณเข้าใจผิด คำถามของฉันเกี่ยวกับสิ่งที่อาจผิดปกติกับโทโพโลยีที่ฉันนำเสนอ เช่น ไคลเอนต์ VPN ที่ทำงานบนเครื่องที่อยู่หลังเราเตอร์ ฉันยังชี้ให้เห็นว่าการติดตั้ง OpenVPN ใหม่ดูเหมือนจะช่วยแก้ปัญหาได้ คุณพูดถึงความเป็นไปได้ในการเรียกใช้ไคลเอนต์ VPN บนเราเตอร์ และฉันตอบว่าไม่สามารถทำได้เนื่องจากไม่มีความสามารถในการกำหนดค่าบนเราเตอร์ ดังนั้นฉันจึงไม่แน่ใจว่าจุดใดที่คำถามของฉันกลายเป็น "ความเข้าใจผิดเกี่ยวกับเราเตอร์ที่บ้าน" เนื่องจากคุณเป็นคนที่พูดถึงเรื่องนี้ตั้งแต่แรกอยู่แล้ว
Cur10usMind avatar
ke flag
ฉันจะไม่ลบคำถามของฉันเนื่องจากฉันเชื่อว่าผู้ใช้รายอื่นอาจประสบปัญหาที่คล้ายกัน และการติดตั้ง OpenVPN ใหม่บนไคลเอนต์อาจเป็นวิธีหนึ่งในการแก้ปัญหา

โพสต์คำตอบ

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