วิธีเลือกไคลเอนต์ Mac VPN สำหรับเกตเวย์ที่คุณมีอยู่แล้ว
SSL VPN เป็นตระกูลผลิตภัณฑ์ ไม่ใช่โปรโตคอลเดียว ถามเจ้าของเกตเวย์เกี่ยวกับไคลเอนต์ โปรไฟล์ และวิธีการลงชื่อเข้าใช้ จากนั้นตรวจสอบเส้นทางและ DNS บน Mac
แอพ Mac VPN หกแอพแสดงบนหน้าดาวน์โหลด และไม่มีแอพใดบอกว่าเกตเวย์นายจ้างของคุณจะยอมรับแอพใด นั่นไม่ใช่ช่องว่างในร้าน มันเป็นช่องว่างในการส่งมอบSSL VPNเป็นตระกูลผลิตภัณฑ์ ไม่ใช่โปรโตคอล ดังนั้นเกตเวย์สองตัวที่มีหน้าจอเข้าสู่ระบบเหมือนกันจึงต้องใช้ไคลเอ็นต์ที่แตกต่างกัน นี่คือลำดับที่ฉันใช้เมื่อมีคนมอบ Mac และที่อยู่เซิร์ฟเวอร์ให้ฉัน: สร้างสิ่งที่เกตเวย์พูด เลือกไคลเอนต์ที่ตรงกัน จากนั้นตรวจสอบเส้นทางและ DNS ก่อนที่คุณจะเชื่อถืออุโมงค์ในการทำงาน
เริ่มต้นด้วยเกตเวย์ ไม่ใช่ App Store
แอปทำงานบน Mac ของคุณ แต่มีอย่างอื่นที่ต้องยอมรับการเชื่อมต่อและให้สิทธิ์การเข้าถึง: เกตเวย์ที่มีผู้ให้บริการ ที่อยู่ การตั้งค่าที่เข้ากันได้ และวิธีการอนุญาตคุณ ไคลเอนต์ฟรีสามารถเป็นซอฟต์แวร์ที่ดีและยังไม่มีสิ่งเหล่านี้เลย การเข้าถึงที่ทำงาน เกตเวย์ที่บ้าน และทางออกอินเทอร์เน็ตเชิงพาณิชย์เป็นจุดเริ่มต้นที่แตกต่างกันสามประการที่เกิดขึ้นในการแชร์หน้าดาวน์โหลด
ก่อนที่จะติดตั้งหรือเปลี่ยนสิ่งใดๆ ให้รับคำตอบสี่ประการจากใครก็ตามที่ใช้บริการ:
โหมดการเข้าถึง:พอร์ทัลเบราว์เซอร์ การเข้าถึงแอปพลิเคชันที่เลือก หรืออุโมงค์เครือข่ายแบบเต็ม สิ่งนี้จะตัดสินใจว่าคุณต้องการลูกค้าหรือไม่
ตระกูลเกตเวย์และรุ่นที่รองรับ:ผลิตภัณฑ์ บริการที่เปิดใช้งาน และเวอร์ชันไคลเอนต์ที่ยังคงรองรับ macOS บิลด์และฮาร์ดแวร์ Mac ของคุณ
การรับรองความถูกต้อง:รหัสผ่านบวก MFA การลงชื่อเข้าใช้เบราว์เซอร์ ใบรับรองอุปกรณ์ หรือการตรวจสอบท่าทาง ไคลเอนต์ที่ไม่มีโฟลว์ที่ได้รับอนุมัติจะเชื่อมต่อแล้วถูกปฏิเสธ
ความเป็นเจ้าของ:แหล่งดาวน์โหลดหรือการจัดการที่เชื่อถือได้ โปรไฟล์ที่ต้องการ และผู้ที่สนับสนุนเมื่อเกิดการขัดข้อง
ความเป็นเจ้าของคือรายการที่ผู้คนข้ามไป บน Mac ที่มีการจัดการ โปรไฟล์มักจะมาถึงผ่านระบบการจัดการองค์กร และการกำหนดค่าที่สร้างขึ้นเองสามารถถูกแทนที่เมื่อเช็คอินครั้งถัดไป ถามว่าคุณต้องติดตั้งอะไรด้วยตัวเองก่อนที่จะมองหาแอปของบุคคลที่สามหรือไม่
SSL VPN เป็นป้ายกำกับครอบครัว ไม่ใช่โปรโตคอล
TLS สามารถปกป้องการเชื่อมต่อในขณะที่การแลกเปลี่ยนเฉพาะผลิตภัณฑ์ภายในนั้นจัดการการเข้าสู่ระบบ การจัดสรรเซสชัน และการรับส่งข้อมูลทันเนล การแลกเปลี่ยนภายในนั้นคือสิ่งที่ลูกค้าต้องดำเนินการ เบราว์เซอร์ที่เข้าถึงหน้าเข้าสู่ระบบเกตเวย์ HTTPS พิสูจน์ห่วงโซ่ใบรับรองและเว็บเซิร์ฟเวอร์ มันไม่ได้พิสูจน์ว่าแอป VPN ที่ไม่เกี่ยวข้องสามารถสร้างอุโมงค์ไปยังเครื่องเดียวกันได้
OpenConnect เป็นภาพประกอบที่ชัดเจนที่สุดที่ฉันรู้ ของมันเอกสารต้นน้ำแสดงรายการโหมดโปรโตคอลแยกกันสำหรับตระกูลเกตเวย์ที่แตกต่างกัน และแยกความสามารถในการทำงานร่วมกันออกจากการสนับสนุนผู้จำหน่ายอย่างเป็นทางการ หากทุก SSL VPN พูดหนึ่งโปรโตคอล โหมดเหล่านั้นจะไม่จำเป็น
โปรไฟล์ OpenVPN มีข้อจำกัดเดียวกันในทางกลับกัน นั่นคือเป็นรูปแบบการนำเข้าสำหรับการปรับใช้ที่เข้ากันได้กับ OpenVPN การแชร์ TLS แบบเอกสารสำเร็จรูปไม่ได้ทำให้เป็นไฟล์การกำหนดค่าสำหรับเกตเวย์องค์กรที่กำหนดเอง นั่นคือสาเหตุที่การเข้าสู่ระบบเบราว์เซอร์ที่ใช้งานได้เป็นผลบวกลวง: การเข้าถึงพอร์ทัลสามารถทำได้สำเร็จในขณะที่ไม่มีอุโมงค์ข้อมูลอยู่ และอุโมงค์ที่เกิดขึ้นยังคงสามารถปฏิเสธได้ด้วยการตรวจสอบท่าทางในภายหลัง
จับคู่ไคลเอ็นต์กับสิ่งที่เกตเวย์พูด
เมื่อครอบครัวเป็นที่รู้จักแล้ว ทางเลือกก็จะแคบลงอย่างรวดเร็ว นี่คือแผนที่ที่ฉันตรวจสอบก่อน และคอลัมน์สุดท้ายมีความสำคัญมากกว่าคะแนนแอปใดๆ
| ครอบครัวเกตเวย์ | ลูกค้าที่ macOS | มีอะไรน่าดู |
|---|---|---|
| IKEv2/IPsec ผู้ขายเป็นกลาง | ไคลเอนต์ macOS ในตัวพร้อมโปรไฟล์ .mobileconfig | ข้อมูลระบุตัวตนของเซิร์ฟเวอร์และโปรไฟล์ที่อาจมีการจัดการ |
| OpenVPN 2.x | Tunnelblick หรือบรรทัดคำสั่ง openvpn | .ovpn พร้อมข้อมูลประจำตัว; ลูกค้าไม่ได้ให้บริการ |
| WireGuard | ไคลเอนต์ WireGuard อย่างเป็นทางการหรือ wireguard-tools | การกำหนดค่าเพียร์ wg show การมองเห็นแตกต่างกันไปตามไคลเอนต์ |
| ผู้ขาย SSL VPN (AnyConnect, Pulse, GlobalProtect, F5, Fortinet) | ลูกค้าของผู้ขาย หรือ OpenConnect ที่มี --protocol ที่ชัดเจน | ชุดค่าผสมที่ไม่รองรับ MFA และการตรวจสอบท่าทาง |
| พอร์ทัลเบราว์เซอร์เท่านั้น | ไม่มีลูกค้า | การเข้าถึงแอปพลิเคชันไม่ใช่อุโมงค์เครือข่าย |
สองแถวสมควรได้รับคำเตือน ไคลเอนต์ macOS ในตัวนั้นเป็นการใช้งาน IKEv2 จริง ไม่ใช่ไคลเอนต์ SSL VPN ทั่วไป: บริการที่ออกแบบมาเพื่อความต้องการนั้นจำเป็นต้องมีโปรไฟล์ที่ถูกต้อง ข้อมูลประจำตัวของเซิร์ฟเวอร์และข้อมูลประจำตัวที่คาดหวัง และบนเครื่องที่ได้รับการจัดการนั้น โปรไฟล์นั้นอาจถูกล็อค OpenConnect ครอบคลุมโปรโตคอลของผู้ขายหลายรายการจากไบนารีเดียว แต่โครงการของตัวเองไม่ได้อ้างสิทธิ์ในการสนับสนุนจากผู้ขาย การสแกนโฮสต์ กฎช่องสัญญาณแยกที่พุชโดยเกตเวย์ หรือโฟลว์ SSO เฉพาะอาจมีอยู่ในไคลเอ็นต์ของผู้จำหน่ายเท่านั้น
WireGuard มีรูปร่างเหมือนกัน บริการจัดหาเพียร์ ไคลเอนต์จัดหาอุโมงค์ และโปรไฟล์ OpenVPN ไม่ใช่สิ่งทดแทน ริ้วรอย macOS หนึ่งอัน: ไคลเอนต์ App Store เก็บอุโมงค์ไว้ข้างในNetwork Extensionดังนั้น wg show จากเครื่องมือ Homebrew จะไม่สามารถรายงานสิ่งใดได้ในขณะที่อินเทอร์เฟซทำงาน ยืนยันเส้นทางและการจราจรแทน
กำหนดค่า จากนั้นตรวจสอบตามลำดับคงที่
ติดตั้งไคลเอนต์หนึ่งตัวและหนึ่งโปรไฟล์ และจดบันทึกสิ่งที่คุณเปลี่ยนแปลง ก่อนที่จะเชื่อมต่อ ให้จับภาพเส้นฐานเพื่อให้คุณสามารถบอกได้ว่าอุโมงค์เปลี่ยนแปลงไปอย่างไร:
scutil --nc list
networksetup -listallnetworkservices
netstat -rn | grep -E "^default|utun"
scutil --dns
เชื่อมต่อกับโปรไฟล์ที่ให้มาและทำซ้ำคำสั่งเดียวกัน สำหรับอุโมงค์แบบเต็ม เส้นทางเริ่มต้นควรชี้ไปที่อินเทอร์เฟซ utun ด้วย split tunneling ควรกำหนดเส้นทางคำนำหน้าภายในเท่านั้น และทางออกสาธารณะของคุณควรดูไม่เปลี่ยนแปลง DNS เป็นครึ่งหนึ่งที่มักจะใช้งานไม่ได้: scutil --dns แสดงรายการตัวแก้ไขตามลำดับที่ระบบจะใช้ และตัวแก้ไขภายในที่อยู่ด้านล่างสาธารณะจะส่งชื่อภายในไปยังเซิร์ฟเวอร์ที่ไม่ถูกต้อง
สำหรับบริการ OpenVPN นั้น Tunnelblick เป็นไคลเอนต์ที่ไม่มีค่าใช้จ่ายที่สมเหตุสมผล และคำแนะนำของตัวมันก็ตรงเกี่ยวกับส่วนที่ขาดหายไป: มันไม่ได้ให้บริการ VPN ดับเบิลคลิกที่ .ovpn ที่คุณได้รับ ให้ Tunnelblick ติดตั้ง และตรวจสอบการเผยแพร่กับเวอร์ชัน macOS ของคุณก่อนที่คุณจะเชื่อถือ.
สำหรับเกตเวย์ของผู้ขาย ฉันมักจะทดสอบด้วย OpenConnect จากบรรทัดคำสั่ง:
brew install openconnect
sudo openconnect --protocol=anyconnect --user=you vpn.example.com
เครื่องมือจะพิมพ์ใบรับรองที่ได้รับและรอก่อนที่จะเชื่อถือเครือข่ายที่ไม่รู้จัก พรอมต์นั้นเป็นคุณสมบัติและการปักหมุดด้วย --servercert pin-sha256:... ดีกว่าการยอมรับคำเตือนที่คุณไม่ได้อ่าน Ctrl-C รื้ออุโมงค์ออก เนื่องจาก openconnect เบื้องหน้าไม่มี kill switch และไม่มีตรรกะในการเชื่อมต่อใหม่ นั่นเป็นเรื่องปกติสำหรับเซสชันการวินิจฉัยและเป็นค่าเริ่มต้นที่ไม่ดีสำหรับงานประจำวัน
เมื่อไม่มีประตูให้ตรงกัน
บางคนมาถึงด้วยปัญหาตรงกันข้าม: ไม่มีเจ้าหน้าที่ ไม่มีที่อยู่ ไม่มีบริการ แอพ Mac ฟรีไม่สามารถสร้างการเข้าถึงขาเข้าที่เราเตอร์ที่บ้านได้ หากคุณต้องการเครือข่ายของคุณเองจากโรงแรม จะต้องมีคนเปิดเกตเวย์ที่บ้าน แพตช์ เผยแพร่ หรือแก้ไขที่อยู่ และตัดสินใจว่าอุปกรณ์ใดที่สามารถเข้าถึงได้
หากคุณต้องการทางออกอินเทอร์เน็ตอื่นแทนที่จะเข้าถึงเครือข่ายส่วนตัว ให้เลือกบริการก่อนไคลเอ็นต์ รายการโปรไฟล์ที่ว่างเปล่าในไคลเอนต์แบบสแตนด์อโลนมักจะไม่ใช่การสมัครสมาชิกฟรีที่เสียหาย อาจไม่มีการสมัครสมาชิกและไม่มีการแนบเซิร์ฟเวอร์ แยกต้นทุนออกจากกัน: สิทธิ์การใช้งานไคลเอ็นต์ แผนบริการ และเกตเวย์ที่ดำเนินการเองเป็นการซื้อที่แตกต่างกันสามรายการ
Work Mac เพิ่มชั้นนโยบาย แอปที่ไม่มีค่าใช้จ่ายอาจผิดพลาดได้แม้ว่าจะเชื่อมต่ออยู่ก็ตาม เนื่องจากไคลเอ็นต์ที่ได้รับอนุมัติอาจบังคับใช้การตรวจสอบอุปกรณ์หรือขั้นตอนการตรวจสอบสิทธิ์ซึ่งเป็นทางเลือกอื่นที่ขาดไป ขอทางเลือกอื่นที่ได้รับอนุมัติแทนการคัดลอกข้อมูลรับรองระหว่างแอปที่ไม่เกี่ยวข้อง และอย่าถือว่าการปิดใช้งานการป้องกันแพลตฟอร์มเป็นการแก้ไขความเข้ากันได้
โปรแกรมดูเดสก์ท็อประยะไกลก็เป็นผลิตภัณฑ์ที่แตกต่างเช่นกัน มันแสดงเซสชันบนคอมพิวเตอร์เครื่องอื่นให้คุณ มันไม่ได้ให้เส้นทางเครือข่ายแก่แอปพลิเคชันในเครื่อง Mac ของคุณตามที่อุโมงค์มอบให้
รายการตรวจสอบสั้นๆ ก่อนเซสชันจริงครั้งแรก
ตั้งชื่อกลุ่มเกตเวย์และโหมดการเข้าถึงเป็นลายลักษณ์อักษร ติดตั้งเฉพาะไคลเอ็นต์ที่ตรงกับกลุ่มเหล่านี้ และบันทึกโปรไฟล์ที่คุณใช้ จากนั้นยืนยันสามสิ่งด้วยการรับส่งข้อมูลจริง: กำหนดเส้นทางอุโมงค์ที่ติดตั้ง ลำดับตัวแก้ไข และแอปพลิเคชันภายในหนึ่งรายการที่เข้าถึงโดยใช้ชื่อแทนที่จะเป็น IP
หากมีบางอย่างล้มเหลว ให้เปลี่ยนตัวแปรทีละตัว: ไคลเอนต์ โปรไฟล์ ขั้นตอนการตรวจสอบสิทธิ์ พอร์ทัลที่โหลดในขณะที่ทันเนลปฏิเสธที่จะเริ่มแยกปัญหาเว็บเซิร์ฟเวอร์ออกจากความเข้ากันได้ของไคลเอนต์ เมื่อฝ่ายบริการงานตอบและเส้นทางสาธารณะเป็นไปตามที่คาดไว้ คุณจะมีการจัดการที่มีชื่อและได้รับการสนับสนุน แทนที่จะต้องเดามากมาย