วิธีเชื่อมต่อกับ VPN ขององค์กรใน Linux โดยใช้ openconnect และ vpn-slice

คุณต้องการใช้ Linux ในที่ทำงาน แต่ VPN ขององค์กรของคุณไม่ยอมให้คุณใช่หรือไม่? บทความนี้อาจช่วยได้แม้ว่าจะไม่แน่ใจก็ตาม ฉันขอเตือนคุณล่วงหน้าว่าฉันไม่เข้าใจปัญหาการบริหารเครือข่ายดีนัก ดังนั้นจึงเป็นไปได้ว่าฉันทำทุกอย่างผิด ในทางกลับกัน เป็นไปได้ที่ฉันสามารถเขียนคำแนะนำในลักษณะที่คนทั่วไปจะเข้าใจได้ ดังนั้นฉันขอแนะนำให้คุณลองใช้

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

คำสั่งส่วนใหญ่ที่ใช้ในคู่มือนี้จำเป็นต้องเรียกใช้ผ่าน sudo ซึ่งถูกลบออกเพื่อความกระชับ เก็บไว้ในใจ.

ที่อยู่ IP ส่วนใหญ่มีความสับสนอย่างมาก ดังนั้นหากคุณเห็นที่อยู่เช่น 435.435.435.435 จะต้องมี IP ปกติบางส่วนอยู่ที่นั่นโดยเฉพาะสำหรับกรณีของคุณ

ฉันมี Ubuntu 18.04 แต่ฉันคิดว่าหากมีการเปลี่ยนแปลงเล็กน้อย คำแนะนำนี้สามารถนำไปใช้กับการแจกแจงอื่นๆ ได้ อย่างไรก็ตาม ในข้อความนี้ Linux == Ubuntu

ซิสโก้คอนเน็ค

ผู้ที่ใช้ Windows หรือ MacOS สามารถเชื่อมต่อกับ VPN องค์กรของเราผ่าน Cisco Connect ซึ่งจำเป็นต้องระบุที่อยู่เกตเวย์ และทุกครั้งที่คุณเชื่อมต่อ ให้ป้อนรหัสผ่านที่ประกอบด้วยส่วนที่ตายตัวและรหัสที่สร้างโดย Google Authenticator

ในกรณีของ Linux ฉันไม่สามารถใช้งาน Cisco Connect ได้ แต่ฉันจัดการให้ Google ให้คำแนะนำในการใช้ openconnect ซึ่งจัดทำขึ้นเพื่อแทนที่ Cisco Connect โดยเฉพาะ

เปิดการเชื่อมต่อ

ตามทฤษฎีแล้ว Ubuntu มีอินเทอร์เฟซแบบกราฟิกพิเศษสำหรับ openconnect แต่มันก็ไม่ได้ผลสำหรับฉัน บางทีมันอาจจะดีขึ้น

บน Ubuntu มีการติดตั้ง openconnect จากตัวจัดการแพ็คเกจ

apt install openconnect

ทันทีหลังการติดตั้ง คุณสามารถลองเชื่อมต่อกับ VPN ได้

openconnect --user poxvuibr vpn.evilcorp.com

vpn.evilcorp.com คือที่อยู่ของ VPN สมมติ
poxvuibr - ชื่อผู้ใช้สมมติ

openconnect จะขอให้คุณป้อนรหัสผ่าน ซึ่งฉันขอเตือนคุณว่าประกอบด้วยส่วนที่ตายตัวและรหัสจาก Google Authenticator จากนั้นจะพยายามเชื่อมต่อกับ VPN หากได้ผล ขอแสดงความยินดี คุณสามารถข้ามตรงกลางซึ่งสร้างความเจ็บปวดมากได้อย่างปลอดภัย และไปยังประเด็นเกี่ยวกับ openconnect ที่ทำงานอยู่เบื้องหลัง หากไม่ได้ผลคุณสามารถดำเนินการต่อได้ แม้ว่าจะใช้งานได้เมื่อเชื่อมต่อเช่นจาก Wi-Fi ของแขกในที่ทำงาน แต่ก็อาจเร็วเกินไปที่จะดีใจ คุณควรลองทำตามขั้นตอนซ้ำจากที่บ้าน

ใบรับรอง

มีความเป็นไปได้สูงที่จะไม่มีอะไรเริ่มต้น และเอาต์พุต openconnect จะมีลักษณะดังนี้:

POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found

Certificate from VPN server "vpn.evilcorp.com" failed verification.
Reason: signer not found
To trust this server in future, perhaps add this to your command line:
    --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress

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

ที่นี่เซิร์ฟเวอร์ส่งใบรับรองมาให้เรา ซึ่งเราสามารถระบุได้ว่ามีการเชื่อมต่อกับเซิร์ฟเวอร์ของบริษัทบ้านเกิดของเรา ไม่ใช่กับนักต้มตุ๋นที่ชั่วร้าย และระบบไม่รู้จักใบรับรองนี้ ดังนั้นเธอจึงไม่สามารถตรวจสอบได้ว่าเซิร์ฟเวอร์นั้นมีจริงหรือไม่ และในกรณีที่มันหยุดทำงาน

เพื่อให้ openconnect เชื่อมต่อกับเซิร์ฟเวอร์ คุณต้องบอกอย่างชัดเจนว่าใบรับรองใดควรมาจากเซิร์ฟเวอร์ VPN โดยใช้คีย์ —servercert

และคุณสามารถค้นหาใบรับรองที่เซิร์ฟเวอร์ส่งถึงเราโดยตรงจากสิ่งที่ openconnect พิมพ์ จากงานชิ้นนี้:

To trust this server in future, perhaps add this to your command line:
    --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress

ด้วยคำสั่งนี้คุณสามารถลองเชื่อมต่ออีกครั้งได้

openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com

บางทีตอนนี้มันใช้งานได้แล้ว คุณก็สามารถเดินหน้าต่อไปจนจบได้ แต่โดยส่วนตัวแล้ว Ubunta แสดงมะเดื่อในรูปแบบนี้ให้ฉันดู

POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found
Connected to HTTPS on vpn.evilcorp.com
XML POST enabled
Please enter your username and password.
POST https://vpn.evilcorp.com/
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 300, Keepalive 30
Set up DTLS failed; using SSL instead
Connected as 192.168.333.222, using SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK answers: File exists
/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf

/ etc / resolv.conf

# Generated by NetworkManager
search gst.evilcorpguest.com
nameserver 127.0.0.53

/run/resolvconf/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 192.168.430.534
nameserver 127.0.0.53
search evilcorp.com gst.publicevilcorp.com

habr.com จะแก้ปัญหาได้ แต่คุณจะไม่สามารถไปที่นั่นได้ ที่อยู่เช่น jira.evilcorp.com จะไม่ได้รับการแก้ไขเลย

เกิดอะไรขึ้นที่นี่ไม่ชัดเจนสำหรับฉัน แต่การทดลองแสดงให้เห็นว่าหากคุณเพิ่มบรรทัดใน /etc/resolv.conf

nameserver 192.168.430.534

ที่อยู่ภายใน VPN จะเริ่มแก้ไขอย่างน่าอัศจรรย์ และคุณสามารถเดินผ่านที่อยู่เหล่านั้นได้ นั่นคือสิ่งที่ DNS กำลังมองหาเพื่อแก้ไขที่อยู่จะมีลักษณะเฉพาะใน /etc/resolv.conf ไม่ใช่ที่อื่น

คุณสามารถตรวจสอบได้ว่ามีการเชื่อมต่อกับ VPN และใช้งานได้โดยไม่ต้องทำการเปลี่ยนแปลงใด ๆ กับ /etc/resolv.conf ในการดำเนินการนี้ เพียงป้อนชื่อสัญลักษณ์ของทรัพยากรจาก VPN ในเบราว์เซอร์ แต่เป็นที่อยู่ IP

เป็นผลให้มีปัญหาสองประการ

  • เมื่อเชื่อมต่อกับ VPN DNS จะไม่ถูกรับ
  • การรับส่งข้อมูลทั้งหมดต้องผ่าน VPN ซึ่งไม่อนุญาตให้เข้าถึงอินเทอร์เน็ต

ฉันจะบอกคุณว่าต้องทำอะไรตอนนี้ แต่ก่อนอื่นให้ใช้ระบบอัตโนมัติเล็กน้อย

การป้อนรหัสผ่านส่วนที่ตายตัวโดยอัตโนมัติ

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

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

สมมติว่าส่วนที่คงที่ของรหัสผ่านคือรหัสผ่านคงที่ และส่วนหนึ่งจาก Google Authenticator คือ 567 รหัสผ่านทั้งหมดสามารถส่งผ่านไปยัง openconnect ผ่านทางอินพุตมาตรฐานโดยใช้อาร์กิวเมนต์ --passwd-on-stdin

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin

ตอนนี้คุณสามารถกลับไปที่คำสั่งที่ป้อนล่าสุดได้ตลอดเวลาและเปลี่ยนเฉพาะส่วนหนึ่งของ Google Authenticator ที่นั่น

VPN ขององค์กรไม่อนุญาตให้คุณท่องอินเทอร์เน็ต

โดยทั่วไปจะไม่สะดวกนักเมื่อต้องใช้คอมพิวเตอร์แยกต่างหากเพื่อไป Habr โดยทั่วไปการไม่สามารถคัดลอก-วางจาก stackoverfow อาจทำให้งานเป็นอัมพาตได้ ดังนั้นจึงจำเป็นต้องดำเนินการบางอย่าง

เราจำเป็นต้องจัดระเบียบมันเพื่อที่ว่าเมื่อคุณต้องการเข้าถึงทรัพยากรจากเครือข่ายภายใน Linux จะไปที่ VPN และเมื่อคุณต้องการไปที่ Habr มันจะไปที่อินเทอร์เน็ต

openconnect หลังจากเปิดตัวและสร้างการเชื่อมต่อกับ VPN แล้ว ให้รันสคริปต์พิเศษซึ่งอยู่ใน /usr/share/vpnc-scripts/vpnc-script ตัวแปรบางตัวจะถูกส่งไปยังสคริปต์เป็นอินพุต และจะกำหนดค่า VPN น่าเสียดายที่ฉันไม่สามารถทราบวิธีแยกการรับส่งข้อมูลระหว่าง VPN ขององค์กรและส่วนที่เหลือของอินเทอร์เน็ตโดยใช้สคริปต์ดั้งเดิมได้

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

การแยกการรับส่งข้อมูลโดยใช้ VPN-Slice

ก่อนอื่นคุณจะต้องติดตั้ง VPN-slice คุณจะต้องคิดออกเอง หากมีคำถามในความคิดเห็น ฉันจะเขียนโพสต์แยกต่างหากเกี่ยวกับเรื่องนี้ แต่นี่เป็นโปรแกรม Python ทั่วไป ดังนั้นจึงไม่มีปัญหาใดๆ ฉันติดตั้งโดยใช้ virtualenv

จากนั้นจะต้องใช้ยูทิลิตีนี้โดยใช้สวิตช์ -script เพื่อระบุว่า openconnect ต้องใช้ vpn-slice แทนสคริปต์มาตรฐาน

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin 
--script "./bin/vpn-slice 192.168.430.0/24  " vpn.evilcorp.com 

--script ถูกส่งผ่านสตริงพร้อมคำสั่งที่ต้องถูกเรียกแทนสคริปต์ ./bin/vpn-slice - เส้นทางไปยังไฟล์ปฏิบัติการ vpn-slice 192.168.430.0/24 - หน้ากากของที่อยู่ที่จะไปที่ใน VPN ที่นี่เราหมายความว่าหากที่อยู่เริ่มต้นด้วย 192.168.430 แสดงว่าจำเป็นต้องค้นหาทรัพยากรที่มีที่อยู่นี้ภายใน VPN

ตอนนี้สถานการณ์น่าจะเกือบจะเป็นปกติแล้ว เกือบ. ตอนนี้คุณสามารถไปที่ Habr และไปที่ทรัพยากรภายในองค์กรด้วย ip ได้ แต่คุณไม่สามารถไปที่ทรัพยากรภายในองค์กรด้วยชื่อสัญลักษณ์ได้ หากคุณระบุการจับคู่ระหว่างชื่อสัญลักษณ์และที่อยู่ในโฮสต์ ทุกอย่างควรจะใช้งานได้ และทำงานจนกว่าไอพีจะเปลี่ยน ขณะนี้ Linux สามารถเข้าถึงอินเทอร์เน็ตหรืออินทราเน็ตได้ ขึ้นอยู่กับ IP แต่ DNS ที่ไม่ใช่องค์กรยังคงใช้เพื่อระบุที่อยู่

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

การแก้ไขไฟล์โฮสต์โดยอัตโนมัติ

หากถาม vpn-slice อย่างสุภาพ หลังจากเพิ่ม VPN แล้วก็สามารถไปที่ DNS ค้นหาที่อยู่ IP ของทรัพยากรที่จำเป็นด้วยชื่อสัญลักษณ์และป้อนลงในโฮสต์ หลังจากปิด VPN ที่อยู่เหล่านี้จะถูกลบออกจากโฮสต์ ในการดำเนินการนี้ คุณจะต้องส่งชื่อสัญลักษณ์ไปยัง vpn-slice เป็นอาร์กิวเมนต์ แบบนี้.

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com 

ตอนนี้ทุกอย่างควรจะใช้ได้ทั้งในสำนักงานและบนชายหาด

ค้นหาที่อยู่ของโดเมนย่อยทั้งหมดใน DNS ที่กำหนดโดย VPN

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

แต่ตอนนี้เราเข้าใจแล้วว่าทำไมความต้องการนี้จึงถูกขจัดออกไป

หากหลังจากเพิ่ม VPN แล้ว คุณดูใน /etc/hosts คุณจะเห็นบรรทัดนี้

192.168.430.534 dns0.tun0 # vpn-slice-tun0 สร้างอัตโนมัติ

และมีการเพิ่มบรรทัดใหม่ใน resolv.conf กล่าวโดยสรุป VPN-slice จะกำหนดตำแหน่งของเซิร์ฟเวอร์ DNS สำหรับ VPN

ตอนนี้เราต้องตรวจสอบให้แน่ใจว่าเพื่อค้นหาที่อยู่ IP ของชื่อโดเมนที่ลงท้ายด้วย evilcorp.com นั้น Linux จะไปที่ DNS ขององค์กร และหากจำเป็นต้องใช้อย่างอื่น ให้ไปที่ค่าเริ่มต้น

ฉัน Googled มาระยะหนึ่งแล้วและพบว่าฟังก์ชันดังกล่าวมีอยู่ใน Ubuntu ทันที นี่หมายถึงความสามารถในการใช้เซิร์ฟเวอร์ DNS ภายในเครื่อง dnsmasq เพื่อแก้ไขชื่อ

นั่นคือคุณสามารถตรวจสอบให้แน่ใจว่า Linux ไปที่เซิร์ฟเวอร์ DNS ในเครื่องเสมอสำหรับที่อยู่ IP ซึ่งจะค้นหา IP บนเซิร์ฟเวอร์ DNS ภายนอกที่เกี่ยวข้อง ทั้งนี้ขึ้นอยู่กับชื่อโดเมน

ในการจัดการทุกอย่างที่เกี่ยวข้องกับเครือข่ายและการเชื่อมต่อเครือข่าย Ubuntu จะใช้ NetworkManager และอินเทอร์เฟซแบบกราฟิกสำหรับการเลือก เช่น การเชื่อมต่อ Wi-Fi เป็นเพียงส่วนหน้าเท่านั้น

เราจะต้องปีนขึ้นไปตามโครงร่างของมัน

  1. สร้างไฟล์ใน /etc/NetworkManager/dnsmasq.d/evilcorp

ที่อยู่=/.evilcorp.com/192.168.430.534

ให้ความสนใจกับจุดที่อยู่ตรงหน้า evilcorp เป็นสัญญาณให้ DNSmasq ทราบว่าควรค้นหาโดเมนย่อยทั้งหมดของ evilcorp.com ใน DNS ขององค์กร

  1. บอก NetworkManager ให้ใช้ dnsmasq สำหรับการจำแนกชื่อ

การกำหนดค่าตัวจัดการเครือข่ายอยู่ใน /etc/NetworkManager/NetworkManager.conf คุณต้องเพิ่มที่นั่น:

[หลัก] dns=dnsmasq

  1. รีสตาร์ท NetworkManager

service network-manager restart

ตอนนี้ หลังจากเชื่อมต่อกับ VPN โดยใช้ openconnect และ vpn-slice แล้ว IP จะถูกกำหนดตามปกติ แม้ว่าคุณจะไม่ได้เพิ่มที่อยู่เชิงสัญลักษณ์ให้กับอาร์กิวเมนต์ของ vpnslice ก็ตาม

วิธีเข้าถึงบริการแต่ละรายการผ่าน VPN

หลังจากที่ฉันเชื่อมต่อ VPN ได้ฉันก็มีความสุขมากเป็นเวลาสองวัน แต่ปรากฏว่าหากฉันเชื่อมต่อ VPN จากนอกเครือข่ายสำนักงาน เมลก็จะไม่ทำงาน อาการเป็นที่คุ้นเคยใช่ไหมคะ?

เมลของเราอยู่ใน mail.publicevilcorp.com ซึ่งหมายความว่าไม่อยู่ภายใต้กฎใน dnsmasq และที่อยู่เซิร์ฟเวอร์เมลจะถูกค้นหาผ่าน DNS สาธารณะ

สำนักงานยังคงใช้ DNS ซึ่งมีที่อยู่นี้ นั่นคือสิ่งที่ฉันคิด. ที่จริงแล้วหลังจากเพิ่มบรรทัดใน dnsmasq แล้ว

ที่อยู่=/mail.publicevilcorp.com/192.168.430.534

สถานการณ์ไม่เปลี่ยนแปลงเลย ip ก็เหมือนเดิม ฉันต้องไปทำงาน

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

ฉันใช้ vpn-slice เพื่อผ่าน VPN ไปยังที่อยู่ที่ขึ้นต้นด้วย 192.168.430 และเมลเซิร์ฟเวอร์ไม่เพียงแต่มีที่อยู่เชิงสัญลักษณ์ที่ไม่ใช่โดเมนย่อยของ evilcorp เท่านั้น แต่ยังไม่มีที่อยู่ IP ที่ขึ้นต้นด้วย 192.168.430 และแน่นอนว่าเขาไม่อนุญาตให้ใครในเครือข่ายทั่วไปเข้ามาหาเขา

เพื่อให้ Linux สามารถผ่าน VPN และไปยังเมลเซิร์ฟเวอร์ได้ คุณต้องเพิ่มมันลงใน VPN-slice ด้วย สมมติว่าที่อยู่ของไปรษณีย์คือ 555.555.555.555

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 555.555.555.555 192.168.430.0/24" vpn.evilcorp.com 

สคริปต์สำหรับเพิ่ม VPN ด้วยอาร์กิวเมนต์เดียว

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

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com 

หากคุณใส่สคริปต์ใน Connect~evilcorp~ คุณสามารถเขียนลงในคอนโซลได้

connect_evil_corp 567987

แต่ตอนนี้คุณยังต้องเก็บคอนโซลที่ openconnect กำลังทำงานอยู่ไว้ด้วยเหตุผลบางประการ

กำลังเรียกใช้ openconnect ในเบื้องหลัง

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

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  

ตอนนี้ยังไม่ชัดเจนว่าบันทึกไปอยู่ที่ไหน โดยทั่วไปแล้ว เราไม่ต้องการบันทึกจริงๆ แต่คุณไม่มีทางรู้ openconnect สามารถเปลี่ยนเส้นทางไปยัง syslog ซึ่งจะถูกเก็บไว้อย่างปลอดภัย คุณต้องเพิ่มสวิตช์ –syslog ให้กับคำสั่ง

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background 
--syslog 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  

ปรากฎว่า openconnect กำลังทำงานอยู่ในเบื้องหลังและไม่รบกวนใครเลย แต่ก็ไม่ชัดเจนว่าจะหยุดมันได้อย่างไร นั่นคือแน่นอนคุณสามารถกรองเอาต์พุต ps โดยใช้ grep และค้นหากระบวนการที่มีชื่อเป็น openconnect ได้ แต่นี่เป็นเรื่องที่น่าเบื่อ ขอบคุณผู้เขียนที่คิดถึงเรื่องนี้เช่นกัน Openconnect มีคีย์ -pid-file ซึ่งคุณสามารถสั่งให้ openconnect เขียนตัวระบุกระบวนการลงในไฟล์ได้

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background  
--syslog 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  
--pid-file ~/vpn-pid

ตอนนี้คุณสามารถฆ่ากระบวนการด้วยคำสั่งได้ตลอดเวลา

kill $(cat ~/vpn-pid)

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

kill $(cat ~/vpn-pid)
#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background 
--syslog 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  
--pid-file ~/vpn-pid

ตอนนี้คุณสามารถเปิดคอมพิวเตอร์ เปิดคอนโซล และเรียกใช้คำสั่ง โดยส่งรหัสจาก Google Authenticator จากนั้นสามารถตอกตะปูคอนโซลได้

ไม่มีชิ้นส่วน VPN แทนที่จะเป็นคำหลัง

กลายเป็นเรื่องยากมากที่จะเข้าใจการใช้ชีวิตโดยปราศจาก VPN-slice ฉันต้องอ่านและ google มาก โชคดีที่หลังจากใช้เวลามากมายกับปัญหา คู่มือทางเทคนิคและแม้แต่มนุษย์ก็อ่านได้ราวกับนิยายที่น่าตื่นเต้น

ด้วยเหตุนี้ ฉันพบว่า vpn-slice เช่นเดียวกับสคริปต์เนทิฟ ปรับเปลี่ยนตารางเส้นทางเพื่อแยกเครือข่าย

ตารางเส้นทาง

พูดง่ายๆ ก็คือตารางในคอลัมน์แรกซึ่งประกอบด้วยที่อยู่ที่ Linux ต้องการผ่านควรขึ้นต้นด้วย และในคอลัมน์ที่สองว่าอะแดปเตอร์เครือข่ายใดบ้างที่ต้องผ่านตามที่อยู่นี้ ในความเป็นจริงมีผู้พูดมากขึ้น แต่สิ่งนี้ไม่ได้เปลี่ยนสาระสำคัญ

ในการดูตารางเส้นทาง คุณต้องรันคำสั่งเส้นทาง ip

default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600 
192.168.430.0/24 dev tun0 scope link 
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.534 metric 600 
192.168.430.534 dev tun0 scope link 

ที่นี่แต่ละบรรทัดมีหน้าที่รับผิดชอบในส่วนที่คุณต้องไปเพื่อส่งข้อความไปยังที่อยู่บางแห่ง ประการแรกคือคำอธิบายว่าที่อยู่ควรเริ่มต้นที่ใด เพื่อให้เข้าใจวิธีการระบุว่า 192.168.0.0/16 หมายความว่าที่อยู่ควรขึ้นต้นด้วย 192.168 คุณต้องค้นหาใน Google ว่าหน้ากากที่อยู่ IP คืออะไร หลังจาก dev จะมีชื่อของอะแดปเตอร์ที่ควรส่งข้อความไป

สำหรับ VPN นั้น Linux ได้สร้างอะแดปเตอร์เสมือน - tun0 เส้นนี้ช่วยให้แน่ใจว่าการรับส่งข้อมูลสำหรับที่อยู่ทั้งหมดที่ขึ้นต้นด้วย 192.168 ผ่านไปได้

192.168.0.0/16 dev tun0 scope link 

คุณยังสามารถดูสถานะปัจจุบันของตารางเส้นทางได้โดยใช้คำสั่ง เส้นทาง -n (ที่อยู่ IP ได้รับการปกปิดชื่ออย่างชาญฉลาด) คำสั่งนี้ให้ผลลัพธ์ในรูปแบบอื่นและโดยทั่วไปจะเลิกใช้แล้ว แต่ผลลัพธ์มักพบในคู่มือบนอินเทอร์เน็ต และคุณต้องสามารถอ่านได้

ตำแหน่งที่ควรเริ่มต้นของที่อยู่ IP สามารถเข้าใจได้จากการรวมกันของคอลัมน์ Destination และ Genmask ส่วนของที่อยู่ IP ที่ตรงกับหมายเลข 255 ใน Genmask จะถูกนำมาพิจารณาด้วย แต่ส่วนที่เป็น 0 จะไม่ถูกนำมาพิจารณา นั่นคือการรวมกันของปลายทาง 192.168.0.0 และ Genmask 255.255.255.0 หมายความว่าหากที่อยู่เริ่มต้นด้วย 192.168.0 คำขอนั้นจะไปตามเส้นทางนี้ และหากปลายทาง 192.168.0.0 แต่เป็น Genmask 255.255.0.0 คำขอไปยังที่อยู่ที่ขึ้นต้นด้วย 192.168 ก็จะไปตามเส้นทางนี้

เพื่อที่จะทราบว่า VPN-slice ทำอะไรได้บ้าง ฉันตัดสินใจดูสถานะของตารางก่อนและหลัง

ก่อนเปิด VPN มันเป็นแบบนี้

route -n 

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0
222.222.222.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0
333.333.333.333 222.222.222.1   255.255.255.255 UGH   0      0        0 wlp3s0

หลังจากเรียก openconnect โดยไม่มี vpn-slice มันก็เป็นแบบนี้

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0
0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0
222.222.222.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0
333.333.333.333 222.222.222.1   255.255.255.255 UGH   0      0        0 wlp3s0
192.168.430.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.430.534 0.0.0.0         255.255.255.255 UH    0      0        0 tun0

และหลังจากเรียก openconnect ร่วมกับ vpn-slice แบบนี้

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0
222.222.222.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0
333.333.333.333 222.222.222.1   255.255.255.255 UGH   0      0        0 wlp3s0
192.168.430.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.430.534 0.0.0.0         255.255.255.255 UH    0      0        0 tun0

จะเห็นได้ว่าหากคุณไม่ได้ใช้ VPN-slice ดังนั้น openconnect จะเขียนอย่างชัดเจนว่าต้องเข้าถึงที่อยู่ทั้งหมด ยกเว้นที่ระบุไว้โดยเฉพาะ ผ่าน VPN

ที่นี่:

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0

ถัดจากนั้นจะมีการระบุเส้นทางอื่นทันทีซึ่งต้องใช้หากที่อยู่ที่ Linux พยายามส่งผ่านไม่ตรงกับมาสก์ใด ๆ จากตาราง

0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0

มีเขียนไว้แล้วที่นี่ว่าในกรณีนี้คุณต้องใช้อแด็ปเตอร์ Wi-Fi มาตรฐาน

ฉันเชื่อว่ามีการใช้เส้นทาง VPN เนื่องจากเป็นเส้นทางแรกในตารางเส้นทาง

และตามทฤษฎีแล้ว หากคุณลบเส้นทางเริ่มต้นนี้ออกจากตารางเส้นทาง เมื่อใช้ร่วมกับ dnsmasq openconnect ควรให้แน่ใจว่าการทำงานปกติ

ฉันเหนื่อย

route del default

และทุกอย่างได้ผล

การกำหนดเส้นทางคำขอไปยังเซิร์ฟเวอร์อีเมลโดยไม่มี VPN-Slice

แต่ฉันยังมีเมลเซิร์ฟเวอร์ที่มีที่อยู่ 555.555.555.555 ซึ่งจำเป็นต้องเข้าถึงผ่าน VPN ด้วย จำเป็นต้องเพิ่มเส้นทางไปยังเส้นทางนั้นด้วยตนเอง

ip route add 555.555.555.555 via dev tun0

และตอนนี้ทุกอย่างเรียบร้อยดี ดังนั้นคุณสามารถทำได้โดยไม่ต้องใช้ VPN-slice แต่คุณต้องรู้ดีว่าคุณกำลังทำอะไรอยู่ ตอนนี้ฉันกำลังคิดที่จะเพิ่มบรรทัดสุดท้ายของสคริปต์ openconnect ดั้งเดิมเพื่อลบเส้นทางเริ่มต้นและเพิ่มเส้นทางสำหรับเมลหลังจากเชื่อมต่อกับ VPN เพียงเพื่อให้ชิ้นส่วนที่เคลื่อนไหวในจักรยานของฉันน้อยลง

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

ที่มา: will.com

เพิ่มความคิดเห็น