จับคู่ไคลเอนต์ VPN ของ Linux กับโปรโตคอลของอุปกรณ์เก่า
อ่านพอร์ตที่อุปกรณ์ประกาศ แล้วติดตั้งไคลเอนต์ที่เหมาะ: pppd บน GRE, strongSwan สำหรับ IKEv1 XAuth หรือ openconnect สำหรับพอร์ทัล
สี่ตระกูลโปรโตคอลครอบคลุมอุปกรณ์เกือบทุกชิ้นที่ยังอยู่ในแร็ค และแต่ละตระกูลล้มเหลวบน Linux ต่างกัน การติดตั้งสิ่งที่โพสต์ในฟอรัมบอกไว้แล้วแก้ไขไปเรื่อย ๆ จนมีอะไรเชื่อมต่อได้คือวิธีที่บ่ายหนึ่งหายไป อ่านอุปกรณ์ก่อน ติดตั้งเป็นลำดับที่สอง ตรวจสอบเป็นลำดับที่สาม
บันทึกสิ่งที่ปลายทางไกลประกาศ
จดโปรโตคอล พอร์ต และการยืนยันตัวตนที่อุปกรณ์คาดหวังไว้ก่อนเปิดตัวจัดการแพ็กเกจ สี่ตระกูลครอบคลุมอุปกรณ์เก่าส่วนใหญ่ และตารางด้านล่างคือการตัดสินใจทั้งหมดในหน้าจอเดียว
| Family | Ports | Linux side |
|---|---|---|
| PPTP | TCP 1723 plus GRE, IP protocol 47 | pppd with a peer file |
| L2TP/IPsec | UDP 500, 4500, 1701 | NetworkManager plugin over strongSwan |
| IKEv1 aggressive with XAuth | UDP 500 | native strongSwan connection |
| AnyConnect-style portal | TCP 443 | openconnect with a TUN device |
คู่มือและกฎไฟร์วอลล์ของอุปกรณ์เองน่าเชื่อถือกว่าชื่อโปรโตคอลบนหน้าเข้าสู่ระบบ อุปกรณ์ที่โฆษณา IPsec อาจพูดได้แค่ IKEv1 และเฟิร์มแวร์รุ่นที่ไม่มีใครติดตั้งอาจเป็นสิ่งที่เพิ่ม IKEv2 ในที่สุด ยืนยันทั้งเส้นทางข้อมูลและพอร์ตตั้งค่า เพราะที่นี่คือจุดที่อุปกรณ์เก่ากับเครือข่ายสมัยใหม่ต่างกัน การผิดพลาดในขั้นนี้หมายถึงการดีบักไคลเอนต์ของคุณกับคุณสมบัติที่อีกฝั่งไม่เคยมี
PPTP: พิสูจน์ GRE ก่อนแก้ไข pppd
PPTP บน Linux ไม่ใช่ดีมอนที่คุณเริ่ม แต่เป็นการเรียก pppd และพารามิเตอร์การเชื่อมต่ออยู่ในไฟล์ peer ที่มีชื่อซึ่ง pppd อ่านเมื่อถูกเรียก การกระจายยังคงแพ็กเกจมันไว้ แม้จุดอ่อนที่รู้จักของโปรโตคอลทำให้ไม่เหมาะกับสิ่งใดที่ละเอียดอ่อน จึงเก็บไว้เฉพาะอุปกรณ์ที่ไม่เสนอสิ่งอื่นใด ดู GRE ขณะไคลเอนต์เจรจา ด้วยการดักจับสั้น ๆ แทนการเดา ความล้มเหลวที่เสียเวลามากที่สุดไม่ใช่การยืนยันตัวตน แต่เป็นเส้นทางข้อมูลที่หายไป
pppd call branch-office
tcpdump -ni any proto gre -c 5
หากการตั้งค่าเสร็จสิ้นและลิงก์ไม่เคยรับส่งข้อมูล ให้สงสัยเส้นทาง GRE ก่อนแตะข้อมูลรับรอง กลุ่มความปลอดภัยบนคลาวด์ต้องมีกฎชัดเจนสำหรับโปรโตคอล 47 และบางเครือข่ายบล็อกมันทั้งหมดโดยไม่มีข้อผิดพลาดให้เห็น ทดสอบจากเครือข่ายที่คุณจะใช้จริง ไม่ใช่จากห้องแล็บที่อนุญาตทุกอย่าง
L2TP/IPsec: ข้อเสนอที่ตรงกันหนึ่งข้อชนะความพยายามสิบครั้ง
อ่านบันทึกของดีมอนแทนกล่องโต้ตอบบนเดสก์ท็อป เพราะกล่องโต้ตอบรวมความล้มเหลวหลายอย่างที่แตกต่างกันไว้ในข้อความเดียว ข้อผิดพลาด NO_PROPOSAL_CHOSEN อยู่ในเฟสแรก ไคลเอนต์เสนอการเข้ารหัส แฮช หรือกลุ่ม Diffie-Hellman ที่เซิร์ฟเวอร์จะไม่ยอมรับ ลิสต์สิ่งที่อุปกรณ์รองรับแล้วเขียนข้อเสนอหนึ่งข้อที่ตรงกัน เพราะการรวมแบบสุ่มมักให้ข้อผิดพลาดเดิมช้ากว่า บนเดสก์ท็อปไคลเอนต์ที่ใช้ได้จริงคือปลั๊กอิน NetworkManager L2TP ที่มี strongSwan หรือ Libreswan อยู่ข้างใต้
สตริงข้อเสนอที่ปลั๊กอินเดสก์ท็อปตีความอย่างหนึ่ง อาจตีความอีกอย่างสำหรับดีมอนที่รับงานต่อไป ดังนั้นรักษาไวยากรณ์ให้เหมาะกับชั้นที่คุณแก้ไข หากอุปกรณ์ต้องการความลับของอุโมงค์ด้วย นั่นเป็นขั้นแยกจากคีย์ IPsec ยืนยันว่าอินเทอร์เฟซถามถึงสิ่งใดก่อนพิมพ์อะไรลงไป
IKEv1 แบบรุกพร้อม XAuth และกรณีพอร์ทัล
ปลายทางสไตล์ FortiGate มักต้องการ โหมดรุกพร้อม XAuth และที่อยู่ในโหมดกำหนดค่าซึ่งปลั๊กอินแบบกราฟิกอาจไม่แสดงเลย ดีมอนดั้งเดิมจัดการได้ และบล็อกด้านล่างคือรูปแบบของการกำหนดค่านั้น ไม่ใช่ไฟล์ สมบูรณ์ ตรวจเอกสารล่าสุดของผู้ขายสำหรับค่าข้อเสนอ
conn branch
keyexchange=ikev1
aggressive=yes
leftauth=psk
leftauth2=xauth
leftsourceip=%config
right=203.0.113.10
strongSwan รุ่นเก่าใช้ xauth=client ในที่ที่รุ่น 5 ใช้ leftauth2=xauth ดังนั้นตัวอย่างที่คัดลอกมาอาจล้มเหลวเพียงเพราะไวยากรณ์ สำหรับพอร์ทัล TLS openconnect ที่พูดโปรโตคอล AnyConnect จัดการ Cisco และแบรนด์ที่เปลี่ยนชื่อส่วนใหญ่ และต้องใช้อุปกรณ์ TUN รวมถึงสิทธิ์ในการกำหนดค่า ส่งที่อยู่พอร์ทัลตามที่เบราว์เซอร์แสดง รวมเส้นทางใด ๆ ที่อุปกรณ์คาดหวัง แล้วตรวจที่อยู่ที่ได้รับก่อนทดสอบสิ่งใดข้างหลัง การสร้างอินเทอร์เฟซล่วงหน้าขจัดความประหลาดใจไปได้หนึ่งประเภทระหว่างการตั้งค่า
sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com
เชื่อมต่อ แล้วตรวจสอบตามลำดับที่แน่นอน
เรียกใช้ตัวจัดการ VPN เพียงตัวเดียวในแต่ละครั้ง เพราะโปรไฟล์ NetworkManager และดีมอนที่เริ่มด้วยมือจะแย่งเส้นทางและ DNS นำโปรไฟล์ลงก่อนทดสอบการเชื่อมต่อแบบแมนนวล และยืนยันว่าไม่มีอินเทอร์เฟซอุโมงค์เก่าหลงเหลือ จากนั้นตรวจสอบตามลำดับนี้ ที่อยู่อุโมงค์ เส้นทางไปยังโฮสต์ภายในเพียงเครื่องเดียวที่คุณต้องการ การแปลงชื่อ และสุดท้ายคำขอจริง ไอคอนสีเขียวพิสูจน์เพียงการยืนยันตัวตนเท่านั้น
ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal
หากขั้นตอนใดล้มเหลว ให้หยุดตรงนั้นแทนที่จะทดสอบขั้นถัดไป เพราะความล้มเหลวของ DNS ใต้เส้นทางที่พังไม่สอนอะไรคุณเลย บันทึกสำเนาโปรไฟล์ที่ใช้งานได้ก่อนทดลอง เพราะไฟล์การเชื่อมต่อที่ลบไปแล้วหายง่ายและสร้างใหม่ลำบาก เก็บค่าข้อเสนอไว้ในบันทึกเดียวกับรุ่นอุปกรณ์และเวอร์ชันเฟิร์มแวร์ เพราะบันทึกนั้นคือความต่างระหว่างการย้ายระบบกับโครงการโบราณคดีเมื่อเปลี่ยนกล่อง