Cách kết nối với VPN công ty trong Linux bằng openconnect và vpn-slice

Bạn có muốn sử dụng Linux tại nơi làm việc nhưng VPN công ty không cho phép bạn? Vậy thì bài viết này có thể giúp ích, mặc dù điều này không chắc chắn. Mình xin cảnh báo trước với các bạn là mình không hiểu rõ vấn đề quản trị mạng nên có thể mình đã làm sai mọi thứ. Mặt khác, có thể tôi có thể viết một hướng dẫn theo cách mà người bình thường có thể hiểu được, vì vậy tôi khuyên bạn nên thử.

Bài viết chứa nhiều thông tin không cần thiết, nhưng nếu không có kiến ​​thức này, tôi sẽ không thể giải quyết những vấn đề bất ngờ xuất hiện với tôi khi thiết lập VPN. Tôi nghĩ rằng bất kỳ ai cố gắng sử dụng hướng dẫn này đều sẽ gặp phải những vấn đề mà tôi không gặp phải và tôi hy vọng rằng thông tin bổ sung này sẽ giúp họ tự giải quyết những vấn đề này.

Hầu hết các lệnh được sử dụng trong hướng dẫn này cần được thực thi thông qua sudo, lệnh này đã bị loại bỏ để cho ngắn gọn. Ghi nhớ.

Hầu hết các địa chỉ IP đã bị xáo trộn nghiêm trọng, vì vậy nếu bạn thấy một địa chỉ như 435.435.435.435 thì chắc chắn phải có một số IP bình thường ở đó, cụ thể cho trường hợp của bạn.

Tôi có Ubuntu 18.04, nhưng tôi nghĩ chỉ với những thay đổi nhỏ, hướng dẫn này có thể được áp dụng cho các bản phân phối khác. Tuy nhiên, trong văn bản này Linux == Ubuntu.

Kết nối Cisco

Những người sử dụng Windows hoặc MacOS có thể kết nối với VPN công ty của chúng tôi thông qua Cisco Connect. VPN này cần chỉ định địa chỉ cổng và mỗi lần bạn kết nối, hãy nhập mật khẩu bao gồm một phần cố định và mã do Google Authenticator tạo.

Trong trường hợp của Linux, tôi không thể chạy Cisco Connect nhưng tôi đã tìm được trên Google một đề xuất sử dụng openconnect, được tạo riêng để thay thế Cisco Connect.

kết nối mở

Về lý thuyết, Ubuntu có giao diện đồ họa đặc biệt dành cho openconnect, nhưng nó không hoạt động với tôi. Có lẽ điều đó tốt hơn.

Trên Ubuntu, openconnect được cài đặt từ trình quản lý gói.

apt install openconnect

Ngay sau khi cài đặt, bạn có thể thử kết nối với VPN

openconnect --user poxvuibr vpn.evilcorp.com

vpn.evilcorp.com là địa chỉ của VPN hư cấu
poxvuibr - tên người dùng hư cấu

openconnect sẽ yêu cầu bạn nhập mật khẩu, để tôi nhắc bạn, bao gồm một phần cố định và mã từ Google Authenticator, sau đó nó sẽ cố gắng kết nối với vpn. Nếu nó hoạt động, xin chúc mừng, bạn có thể bỏ qua phần giữa một cách an toàn, điều này gây nhiều khó khăn và chuyển sang điểm về openconnect chạy ở chế độ nền. Nếu nó không hoạt động, thì bạn có thể tiếp tục. Mặc dù nếu nó hoạt động khi kết nối, chẳng hạn như từ Wi-Fi của khách tại nơi làm việc, thì có thể còn quá sớm để vui mừng, bạn nên cố gắng lặp lại quy trình ở nhà.

Giấy chứng nhận

Có khả năng cao là sẽ không có gì bắt đầu và đầu ra openconnect sẽ trông giống như thế này:

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

Một mặt, điều này thật khó chịu vì không có kết nối với VPN, nhưng mặt khác, về nguyên tắc, cách khắc phục vấn đề này là rõ ràng.

Tại đây, máy chủ đã gửi cho chúng tôi một chứng chỉ, qua đó chúng tôi có thể xác định rằng kết nối đang được thực hiện với máy chủ của công ty bản địa của chúng tôi chứ không phải cho một kẻ lừa đảo độc ác và hệ thống không xác định được chứng chỉ này. Và do đó cô ấy không thể kiểm tra xem máy chủ có thật hay không. Và vì vậy, đề phòng trường hợp nó ngừng hoạt động.

Để openconnect kết nối với máy chủ, bạn cần cho nó biết rõ ràng chứng chỉ nào sẽ đến từ máy chủ VPN bằng cách sử dụng khóa —servercert

Và bạn có thể tìm ra chứng chỉ nào mà máy chủ đã gửi trực tiếp cho chúng tôi từ những gì openconnect đã in. Đây là từ phần này:

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

Với lệnh này, bạn có thể thử kết nối lại

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

Có lẽ bây giờ nó đã hoạt động, sau đó bạn có thể chuyển sang phần cuối. Nhưng cá nhân tôi thì Ubunta đã cho tôi xem một con sung ở dạng này

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 sẽ giải quyết nhưng bạn sẽ không thể truy cập vào đó. Các địa chỉ như jira.evilcorp.com hoàn toàn không được giải quyết.

Điều gì đã xảy ra ở đây tôi không rõ ràng. Nhưng thử nghiệm cho thấy rằng nếu bạn thêm dòng vào /etc/resolv.conf

nameserver 192.168.430.534

khi đó các địa chỉ bên trong VPN sẽ bắt đầu phân giải một cách kỳ diệu và bạn có thể xem qua chúng, tức là DNS đang tìm kiếm để phân giải các địa chỉ cụ thể trong /etc/resolv.conf chứ không phải ở nơi nào khác.

Bạn có thể xác minh rằng có kết nối với VPN và nó hoạt động mà không thực hiện bất kỳ thay đổi nào đối với /etc/resolv.conf; để thực hiện việc này, chỉ cần nhập vào trình duyệt không phải tên tượng trưng của tài nguyên từ VPN mà là địa chỉ IP của nó

Kết quả là có hai vấn đề

  • Khi kết nối với VPN, dns của nó không được chọn
  • tất cả lưu lượng truy cập đều đi qua VPN, không cho phép truy cập Internet

Tôi sẽ cho bạn biết phải làm gì bây giờ, nhưng trước tiên hãy tự động hóa một chút.

Tự động nhập phần cố định của mật khẩu

Đến bây giờ, rất có thể bạn đã nhập mật khẩu của mình ít nhất năm lần và quy trình này đã khiến bạn mệt mỏi. Thứ nhất, vì mật khẩu dài, thứ hai, vì khi nhập bạn cần phải phù hợp trong một khoảng thời gian cố định

Giải pháp cuối cùng cho vấn đề không có trong bài viết, nhưng bạn có thể đảm bảo rằng phần cố định của mật khẩu không phải nhập nhiều lần.

Giả sử phần cố định của mật khẩu là fixPassword và phần từ Google Authenticator là 567 987. Toàn bộ mật khẩu có thể được chuyển tới openconnect thông qua đầu vào tiêu chuẩn bằng cách sử dụng đối số --passwd-on-stdin .

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

Giờ đây, bạn có thể liên tục quay lại lệnh đã nhập gần đây nhất và chỉ thay đổi một phần của Google Authenticator ở đó.

VPN công ty không cho phép bạn lướt Internet.

Nói chung là không bất tiện lắm khi phải dùng máy tính riêng để đến Habr. Việc không thể sao chép-dán từ stackoverfow nói chung có thể làm tê liệt công việc, vì vậy cần phải làm gì đó.

Chúng ta cần tổ chức nó bằng cách nào đó để khi bạn cần truy cập tài nguyên từ mạng nội bộ, Linux sẽ truy cập VPN và khi bạn cần truy cập Habr, nó sẽ truy cập Internet.

openconnect, sau khi khởi chạy và thiết lập kết nối với vpn, sẽ thực thi một tập lệnh đặc biệt, nằm trong /usr/share/vpnc-scripts/vpnc-script. Một số biến được chuyển tới tập lệnh làm đầu vào và nó sẽ cấu hình VPN. Thật không may, tôi không thể tìm ra cách phân chia luồng lưu lượng giữa VPN công ty và phần còn lại của Internet bằng tập lệnh gốc.

Rõ ràng, tiện ích vpn-slice được phát triển đặc biệt dành cho những người như tôi, tiện ích này cho phép bạn gửi lưu lượng truy cập qua hai kênh mà không cần nhảy múa với tambourine. Chà, nghĩa là bạn sẽ phải nhảy, nhưng bạn không cần phải là một pháp sư.

Phân tách lưu lượng bằng vpn-slice

Đầu tiên, bạn sẽ phải cài đặt vpn-slice, bạn sẽ phải tự mình tìm ra điều này. Nếu có thắc mắc trong phần bình luận, tôi sẽ viết một bài riêng về vấn đề này. Nhưng đây là một chương trình Python thông thường nên sẽ không có bất kỳ khó khăn nào. Tôi đã cài đặt bằng virtualenv.

Và sau đó tiện ích phải được áp dụng, sử dụng khóa chuyển -script, biểu thị để openconnect rằng thay vì tập lệnh tiêu chuẩn, bạn cần sử dụng 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 được truyền một chuỗi có lệnh cần được gọi thay vì tập lệnh. ./bin/vpn-slice - đường dẫn đến tệp thực thi vpn-slice 192.168.430.0/24 - mặt nạ của các địa chỉ cần truy cập trong vpn. Ở đây, ý của chúng tôi là nếu địa chỉ bắt đầu bằng 192.168.430 thì tài nguyên có địa chỉ này cần được tìm kiếm bên trong VPN

Tình hình bây giờ sẽ gần như bình thường. Hầu hết. Bây giờ bạn có thể truy cập Habr và bạn có thể truy cập tài nguyên nội bộ công ty bằng ip, nhưng bạn không thể truy cập tài nguyên nội bộ công ty bằng tên tượng trưng. Nếu bạn chỉ định sự trùng khớp giữa tên tượng trưng và địa chỉ trong máy chủ thì mọi thứ sẽ hoạt động. Và làm việc cho đến khi ip thay đổi. Linux hiện có thể truy cập Internet hoặc mạng nội bộ, tùy thuộc vào IP. Nhưng DNS phi công ty vẫn được sử dụng để xác định địa chỉ.

Vấn đề cũng có thể biểu hiện ở dạng này - tại nơi làm việc mọi thứ đều ổn, nhưng ở nhà, bạn chỉ có thể truy cập tài nguyên nội bộ của công ty qua IP. Điều này là do khi bạn kết nối với Wi-Fi của công ty, DNS của công ty cũng được sử dụng và các địa chỉ tượng trưng từ VPN sẽ được phân giải trong đó, mặc dù thực tế là vẫn không thể truy cập địa chỉ đó mà không sử dụng VPN.

Tự động sửa đổi tập tin máy chủ

Nếu vpn-slice được hỏi một cách lịch sự, thì sau khi nâng cấp VPN, nó có thể truy cập DNS của nó, tìm ở đó địa chỉ IP của các tài nguyên cần thiết theo tên tượng trưng của chúng và nhập chúng vào máy chủ. Sau khi tắt VPN, các địa chỉ này sẽ bị xóa khỏi máy chủ. Để làm điều này, bạn cần chuyển các tên tượng trưng cho vpn-slice làm đối số. Như thế này.

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 

Bây giờ mọi thứ sẽ hoạt động cả trong văn phòng và trên bãi biển.

Tìm kiếm địa chỉ của tất cả các tên miền phụ trong DNS do VPN cung cấp

Nếu có ít địa chỉ trong mạng thì phương pháp tự động sửa đổi tệp máy chủ hoạt động khá tốt. Nhưng nếu có nhiều tài nguyên trên mạng thì bạn sẽ cần liên tục thêm các dòng như zoidberg.test.evilcorp.com zoidberg là tên của một trong những băng ghế thử nghiệm.

Nhưng bây giờ chúng ta đã hiểu một chút tại sao nhu cầu này có thể được loại bỏ.

Nếu sau khi nâng cấp VPN, bạn nhìn vào /etc/hosts, bạn có thể thấy dòng này

192.168.430.534 dns0.tun0 #vpn-slice-tun0 TỰ ĐỘNG TẠO

Và một dòng mới đã được thêm vào resolv.conf. Nói tóm lại, vpn-slice bằng cách nào đó đã xác định được vị trí của máy chủ dns cho vpn.

Bây giờ chúng ta cần đảm bảo rằng để tìm ra địa chỉ IP của một tên miền kết thúc bằng evilcorp.com, Linux sẽ truy cập DNS của công ty và nếu cần thứ gì khác thì hãy chuyển đến địa chỉ mặc định.

Tôi đã tìm kiếm trên Google một thời gian và thấy rằng chức năng như vậy có sẵn trong Ubuntu. Điều này có nghĩa là khả năng sử dụng máy chủ DNS cục bộ dnsmasq để phân giải tên.

Nghĩa là, bạn có thể đảm bảo rằng Linux luôn truy cập máy chủ DNS cục bộ để tìm địa chỉ IP, do đó, tùy thuộc vào tên miền, sẽ tìm kiếm IP trên máy chủ DNS bên ngoài tương ứng.

Để quản lý mọi thứ liên quan đến mạng và kết nối mạng, Ubuntu sử dụng NetworkManager và giao diện đồ họa để chọn, chẳng hạn như kết nối Wi-Fi, chỉ là giao diện người dùng của nó.

Chúng ta sẽ cần phải leo lên trong cấu hình của nó.

  1. Tạo một tệp trong /etc/NetworkManager/dnsmasq.d/evilcorp

địa chỉ=/.evilcorp.com/192.168.430.534

Hãy chú ý đến điểm phía trước của evilcorp. Nó báo hiệu cho dnsmasq rằng tất cả các tên miền phụ của evilcorp.com phải được tìm kiếm trong dns của công ty.

  1. Yêu cầu NetworkManager sử dụng dnsmasq để phân giải tên

Cấu hình trình quản lý mạng được đặt trong /etc/NetworkManager/NetworkManager.conf Bạn cần thêm vào đó:

[chính] dns=dnsmasq

  1. Khởi động lại Trình quản lý mạng

service network-manager restart

Bây giờ, sau khi kết nối với VPN bằng openconnect và vpn-slice, ip sẽ được xác định bình thường, ngay cả khi bạn không thêm địa chỉ tượng trưng vào các đối số của vpnslice.

Cách truy cập các dịch vụ riêng lẻ qua VPN

Sau khi kết nối được với VPN, tôi rất vui trong hai ngày, và sau đó hóa ra là nếu tôi kết nối với VPN từ bên ngoài mạng văn phòng thì thư không hoạt động. Triệu chứng này rất quen thuộc phải không?

Thư của chúng tôi được đặt tại mail.publicevilcorp.com, có nghĩa là nó không tuân theo quy tắc trong dnsmasq và địa chỉ máy chủ thư được tìm kiếm thông qua DNS công cộng.

Chà, văn phòng vẫn sử dụng DNS, nơi chứa địa chỉ này. Đó là những gì tôi nghĩ. Trên thực tế, sau khi thêm dòng vào dnsmasq

địa chỉ=/mail.publicevilcorp.com/192.168.430.534

tình hình vẫn không thay đổi chút nào. ip vẫn giữ nguyên. Tôi phải đi làm.

Và chỉ sau này, khi tôi tìm hiểu sâu hơn về tình huống và hiểu được vấn đề một chút, một người thông minh đã chỉ cho tôi cách giải quyết. Cần phải kết nối với máy chủ thư không chỉ như vậy mà còn thông qua VPN

Tôi sử dụng vpn-slice để truy cập VPN tới các địa chỉ bắt đầu bằng 192.168.430. Và máy chủ thư không chỉ có một địa chỉ tượng trưng không phải là tên miền phụ của evilcorp, nó còn không có địa chỉ IP bắt đầu bằng 192.168.430. Và tất nhiên anh ta không cho phép bất cứ ai trong mạng lưới chung đến với mình.

Để Linux đi qua VPN và đến máy chủ thư, bạn cũng cần thêm nó vào vpn-slice. Giả sử địa chỉ của người gửi thư là 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 

Tập lệnh nâng cao VPN với một đối số

Tất cả điều này, tất nhiên, không thuận tiện lắm. Có, bạn có thể lưu văn bản vào một tệp và sao chép-dán nó vào bảng điều khiển thay vì gõ bằng tay, nhưng điều đó vẫn không dễ chịu cho lắm. Để làm cho quá trình này dễ dàng hơn, bạn có thể gói lệnh trong một tập lệnh nằm trong PATH. Và sau đó bạn sẽ chỉ cần nhập mã nhận được từ 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 

Nếu bạn đặt tập lệnh vào connect~evilcorp~ bạn chỉ cần viết vào bảng điều khiển

connect_evil_corp 567987

Nhưng bây giờ bạn vẫn phải giữ bảng điều khiển trong đó openconnect đang chạy vì lý do nào đó

Chạy openconnect ở chế độ nền

May mắn thay, các tác giả của openconnect đã quan tâm đến chúng tôi và thêm một khóa đặc biệt vào chương trình -background, giúp chương trình hoạt động ở chế độ nền sau khi khởi chạy. Nếu bạn chạy nó như thế này, bạn có thể đóng bảng điều khiển sau khi khởi chạy

#!/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  

Bây giờ không rõ nhật ký sẽ đi đâu. Nói chung, chúng tôi không thực sự cần nhật ký, nhưng bạn không bao giờ biết được. openconnect có thể chuyển hướng chúng đến nhật ký hệ thống, nơi chúng sẽ được giữ an toàn và bảo mật. bạn cần thêm khóa chuyển –syslog vào lệnh

#!/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  

Và do đó, hóa ra openconnect đang hoạt động ở đâu đó trong nền và không làm phiền bất kỳ ai, nhưng không rõ làm cách nào để ngăn chặn nó. Nghĩa là, tất nhiên, bạn có thể lọc đầu ra ps bằng grep và tìm kiếm một quy trình có tên chứa openconnect, nhưng điều này có phần tẻ nhạt. Cảm ơn các tác giả đã nghĩ về điều này quá. Openconnect có một khóa -pid-file, với khóa này bạn có thể hướng dẫn openconnect ghi mã định danh tiến trình của nó vào một tệp.

#!/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

Bây giờ bạn luôn có thể giết một tiến trình bằng lệnh

kill $(cat ~/vpn-pid)

Nếu không có quy trình, kill sẽ nguyền rủa nhưng sẽ không đưa ra lỗi. Nếu tệp không có ở đó thì cũng sẽ không có điều gì xấu xảy ra, vì vậy bạn có thể tắt tiến trình ở dòng đầu tiên của tập lệnh một cách an toàn.

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

Bây giờ bạn có thể bật máy tính của mình, mở bảng điều khiển và chạy lệnh, chuyển mã từ Google Authenticator cho nó. Bảng điều khiển sau đó có thể được đóng đinh xuống.

Không có phần VPN. Thay vì lời bạt

Hóa ra rất khó hiểu cách sống mà không có VPN-slice. Tôi đã phải đọc và google rất nhiều. May mắn thay, sau khi dành quá nhiều thời gian cho một vấn đề, các hướng dẫn kỹ thuật và thậm chí cả con người openconnect đọc như những cuốn tiểu thuyết thú vị.

Kết quả là tôi phát hiện ra rằng vpn-slice, giống như tập lệnh gốc, sửa đổi bảng định tuyến thành các mạng riêng biệt.

Bảng định tuyến

Nói một cách đơn giản, đây là một bảng trong cột đầu tiên chứa địa chỉ mà Linux muốn truy cập phải bắt đầu bằng và trong cột thứ hai, bộ điều hợp mạng sẽ đi qua địa chỉ này. Trên thực tế, có nhiều người nói hơn, nhưng điều này không làm thay đổi bản chất.

Để xem bảng định tuyến, bạn cần chạy lệnh ip Route

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 

Ở đây, mỗi dòng chịu trách nhiệm về nơi bạn cần đến để gửi tin nhắn đến một địa chỉ nào đó. Đầu tiên là mô tả về nơi địa chỉ sẽ bắt đầu. Để hiểu cách xác định 192.168.0.0/16 có nghĩa là địa chỉ phải bắt đầu bằng 192.168, bạn cần tra cứu trên Google mặt nạ địa chỉ IP là gì. Sau dev là tên của bộ điều hợp mà tin nhắn sẽ được gửi đến.

Đối với VPN, Linux đã tạo một bộ điều hợp ảo - tun0. Đường này đảm bảo rằng lưu lượng truy cập cho tất cả các địa chỉ bắt đầu bằng 192.168 sẽ đi qua nó

192.168.0.0/16 dev tun0 scope link 

Bạn cũng có thể xem trạng thái hiện tại của bảng định tuyến bằng lệnh tuyến đường -n (Địa chỉ IP được ẩn danh một cách khéo léo) Lệnh này tạo ra kết quả ở dạng khác và thường không được dùng nữa, nhưng đầu ra của nó thường được tìm thấy trong các hướng dẫn sử dụng trên Internet và bạn cần có khả năng đọc được.

Nơi bắt đầu địa chỉ IP của tuyến đường có thể được hiểu từ sự kết hợp của cột Đích và Genmask. Những phần của địa chỉ IP tương ứng với số 255 trong Genmask đều được tính đến, nhưng những phần có số 0 thì không. Nghĩa là, sự kết hợp giữa Đích 192.168.0.0 và Genmask 255.255.255.0 có nghĩa là nếu địa chỉ bắt đầu bằng 192.168.0 thì yêu cầu tới địa chỉ đó sẽ đi theo tuyến đường này. Và nếu Destination 192.168.0.0 nhưng Genmask 255.255.0.0 thì các yêu cầu tới các địa chỉ bắt đầu bằng 192.168 sẽ đi theo lộ trình này

Để tìm hiểu vpn-slice thực sự làm gì, tôi quyết định xem xét trạng thái của các bảng trước và sau

Trước khi bật VPN thì nó như thế này

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

Sau khi gọi openconnect mà không có vpn-slice thì nó trở thành như thế này

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

Và sau khi gọi openconnect kết hợp với vpn-slice như thế này

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

Có thể thấy rằng nếu bạn không sử dụng vpn-slice thì openconnect ghi rõ ràng rằng tất cả các địa chỉ, ngoại trừ những địa chỉ được chỉ định cụ thể, phải được truy cập thông qua vpn.

Ngay tại đây:

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0

Ở đó, bên cạnh nó, ngay lập tức chỉ ra một đường dẫn khác, đường dẫn này phải được sử dụng nếu địa chỉ mà Linux đang cố gắng truyền qua không khớp với bất kỳ mặt nạ nào trong bảng.

0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0

Ở đây đã viết rằng trong trường hợp này bạn cần sử dụng bộ điều hợp Wi-Fi tiêu chuẩn.

Tôi tin rằng đường dẫn VPN được sử dụng vì đây là đường dẫn đầu tiên trong bảng định tuyến.

Và về mặt lý thuyết, nếu bạn loại bỏ đường dẫn mặc định này khỏi bảng định tuyến thì kết hợp với dnsmasq openconnect sẽ đảm bảo hoạt động bình thường.

Tôi đã thử

route del default

Và mọi thứ đều hiệu quả.

Định tuyến yêu cầu đến máy chủ thư không có vpn-slice

Nhưng tôi cũng có một máy chủ thư có địa chỉ 555.555.555.555, máy chủ này cũng cần được truy cập qua VPN. Đường dẫn đến nó cũng cần được thêm thủ công.

ip route add 555.555.555.555 via dev tun0

Và bây giờ mọi thứ đều ổn. Vì vậy, bạn có thể làm mà không cần vpn-slice, nhưng bạn cần biết rõ mình đang làm gì. Bây giờ tôi đang suy nghĩ xem có nên thêm vào dòng cuối cùng của tập lệnh openconnect gốc để xóa tuyến mặc định và thêm tuyến cho người gửi thư sau khi kết nối với VPN hay không, chỉ để có ít bộ phận chuyển động hơn trong xe đạp của tôi.

Có lẽ, lời bạt này sẽ đủ để ai đó hiểu cách thiết lập VPN. Nhưng trong khi tôi đang cố gắng hiểu những gì và làm như thế nào, tôi đã đọc khá nhiều hướng dẫn như vậy phù hợp với tác giả, nhưng vì lý do nào đó không phù hợp với tôi và tôi quyết định thêm vào đây tất cả những phần mà tôi tìm thấy. Tôi sẽ rất vui về điều gì đó như thế.

Nguồn: www.habr.com

Thêm một lời nhận xét