직장에서 Linux를 사용하고 싶지만 회사 VPN이 허용하지 않습니까? 그렇다면 이 기사가 도움이 될 수 있지만 확실하지는 않습니다. 제가 네트워크 관리 문제를 잘 이해하지 못해서 모든 일을 잘못했을 가능성이 있다는 점을 미리 말씀드리고 싶습니다. 한편, 일반 사람들도 이해할 수 있는 방식으로 가이드를 작성할 수도 있으니 꼭 시도해 보시길 권합니다.

기사에는 불필요한 정보가 많이 포함되어 있지만, 이 지식이 없었다면 VPN 설정 시 예기치 않게 발생한 문제를 해결할 수 없었을 것입니다. 이 가이드를 사용하려는 사람은 누구나 내가 겪지 않은 문제를 겪게 될 것이라고 생각하며, 이 추가 정보가 이러한 문제를 스스로 해결하는 데 도움이 되기를 바랍니다.

이 가이드에 사용된 대부분의 명령은 간결성을 위해 제거된 sudo를 통해 실행해야 합니다. 명심하세요.

대부분의 IP 주소는 심각하게 난독화되어 있으므로 435.435.435.435와 같은 주소가 표시되면 해당 사례에 맞는 일반 IP가 있어야 합니다.

Ubuntu 18.04가 있지만 약간만 변경하면 이 가이드를 다른 배포판에도 적용할 수 있을 것 같습니다. 그러나 이 텍스트에서는 Linux == Ubuntu입니다.

시스코 커넥트

Windows 또는 MacOS를 사용하는 사용자는 Cisco Connect를 통해 회사 VPN에 연결할 수 있으며, 게이트웨이 주소를 지정하고 연결할 때마다 고정된 부분과 Google Authenticator에서 생성된 코드로 구성된 비밀번호를 입력해야 합니다.

Linux의 경우 Cisco Connect를 실행할 수 없었지만 Cisco Connect를 대체하기 위해 특별히 만들어진 openconnect를 사용하라는 권장 사항을 Google에 검색했습니다.

오픈커넥트

이론적으로 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가 서버에 연결하려면 —servercert 키를 사용하여 VPN 서버에서 어떤 인증서를 가져와야 하는지 명시적으로 알려야 합니다.

그리고 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

아마도 이제 작동 중일 것입니다. 그러면 끝까지 진행할 수 있습니다. 그런데 개인적으로 우분타가 이런 형태의 무화과를 보여줬어요

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

/ 기타 / 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을 통과하므로 인터넷 액세스가 허용되지 않습니다.

지금 무엇을 해야 할지 말씀드리겠습니다. 먼저 약간의 자동화를 해보겠습니다.

고정된 비밀번호 부분 자동 입력

지금쯤이면 이미 비밀번호를 다섯 번 이상 입력했을 것이며 이 절차로 인해 이미 지쳤을 것입니다. 첫째, 비밀번호가 길기 때문이고, 둘째, 입력할 때 정해진 시간 내에 들어가야 하기 때문입니다.

문제에 대한 최종 해결책은 기사에 포함되지 않았지만 고정된 비밀번호 부분을 여러 번 입력하지 않아도 된다는 점을 확인할 수 있습니다.

비밀번호의 고정된 부분이fixedPassword이고 Google Authenticator의 부분이 567이라고 가정하면 --passwd-on-stdin 인수를 사용하여 표준 입력을 통해 전체 비밀번호를 openconnect에 전달할 수 있습니다.

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를 이용하여 설치했습니다.

그런 다음 표준 스크립트 대신 vpn-slice를 사용해야 함을 openconnect에 나타내는 -script 스위치를 사용하여 유틸리티를 적용해야 합니다.

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로 갈 수 있지만, 심볼릭 이름으로는 기업 내부 리소스로 갈 수 없습니다. 호스트의 기호 이름과 주소가 일치하도록 지정하면 모든 것이 작동합니다. 그리고 IP가 바뀔 때까지 작업하세요. 이제 Linux는 IP에 따라 인터넷이나 인트라넷에 액세스할 수 있습니다. 그러나 주소를 확인하는 데는 여전히 비기업 DNS가 사용됩니다.

문제는 다음과 같은 형태로 나타날 수도 있습니다. 직장에서는 모든 것이 정상이지만 집에서는 IP를 통해서만 내부 회사 리소스에 액세스할 수 있습니다. 기업 Wi-Fi에 연결하면 VPN을 사용하지 않고 해당 주소로 이동할 수 없음에도 불구하고 기업 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 

이제 사무실과 해변 모두에서 모든 것이 작동할 것입니다.

VPN이 제공한 DNS의 모든 하위 도메인 주소를 검색하세요.

네트워크 내에 주소가 거의 없는 경우 호스트 파일을 자동으로 수정하는 접근 방식이 매우 효과적입니다. 그러나 네트워크에 리소스가 많으면 zoidberg.test.evilcorp.com과 같은 줄을 스크립트에 지속적으로 추가해야 합니다. zoidberg는 테스트 벤치 중 하나의 이름입니다.

그러나 이제 우리는 이러한 필요성이 제거될 수 있는 이유를 조금 이해했습니다.

VPN을 올린 후 /etc/hosts를 보면 다음 줄을 볼 수 있습니다.

192.168.430.534 dns0.tun0 # vpn-slice-tun0 자동 생성됨

그리고 resolv.conf에 새로운 줄이 추가되었습니다. 간단히 말해서, vpn-slice는 VPN용 DNS 서버의 위치를 ​​어떻게든 결정했습니다.

이제 evilcorp.com으로 끝나는 도메인 이름의 IP 주소를 찾으려면 Linux가 기업 DNS로 이동하고, 다른 것이 필요한 경우 기본 DNS로 이동하는지 확인해야 합니다.

나는 꽤 오랫동안 구글링을 했고 그러한 기능이 우분투에서 즉시 사용 가능하다는 것을 발견했습니다. 이는 로컬 DNS 서버 dnsmasq를 사용하여 이름을 확인하는 기능을 의미합니다.

즉, Linux가 IP 주소를 찾기 위해 항상 로컬 DNS 서버로 이동하도록 할 수 있으며, 그러면 도메인 이름에 따라 해당 외부 DNS 서버에서 IP를 찾습니다.

네트워크 및 네트워크 연결과 관련된 모든 것을 관리하기 위해 Ubuntu는 NetworkManager를 사용하며, 예를 들어 Wi-Fi 연결을 선택하기 위한 그래픽 인터페이스는 단지 프런트 엔드일 뿐입니다.

우리는 그 구성을 올라가야 할 것입니다.

1. /etc/NetworkManager/dnsmasq.d/evilcorp에 파일을 생성합니다.

주소=/.evilcorp.com/192.168.430.534

evilcorp 앞의 지점에 주목하세요. evilcorp.com의 모든 하위 도메인을 기업 DNS에서 검색해야 함을 dnsmasq에 알립니다.

1. NetworkManager에게 이름 확인을 위해 dnsmasq를 사용하도록 지시

네트워크 관리자 구성은 /etc/NetworkManager/NetworkManager.conf에 있습니다. 여기에 다음을 추가해야 합니다.

[메인] dns=dnsmasq

1. NetworkManager 다시 시작

service network-manager restart

이제 openconnect 및 vpn-slice를 사용하여 VPN에 연결하면 vpnslice에 대한 인수에 기호 주소를 추가하지 않아도 IP가 정상적으로 결정됩니다.

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의 하위 도메인이 아닌 심볼릭 주소가 있을 뿐만 아니라, 192.168.430으로 시작하는 IP 주소도 없습니다. 물론 그는 일반 네트워크의 어느 누구도 자신에게 오는 것을 허용하지 않습니다.

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 OTP에서 받은 코드만 입력하면 됩니다.

#!/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가 백그라운드 어딘가에서 작동하고 있으며 누구에게도 방해가 되지 않는 것으로 밝혀졌지만 이를 중지하는 방법은 명확하지 않습니다. 즉, 물론 grep을 사용하여 ps 출력을 필터링하고 이름에 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은 저주를 퍼붓지만 오류를 발생시키지는 않습니다. 파일이 없으면 나쁜 일도 일어나지 않으므로 스크립트의 첫 번째 줄에서 프로세스를 안전하게 종료할 수 있습니다.

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-슬라이스 없이 살아가는 방법을 이해하는 것은 매우 어려웠습니다. 나는 책을 많이 읽고 구글링을 해야 했다. 다행스럽게도 문제를 해결하는 데 너무 많은 시간을 소비한 후에는 기술 매뉴얼과 심지어 man openconnect도 흥미진진한 소설처럼 읽혔습니다.

그 결과, vpn-slice도 네이티브 스크립트와 마찬가지로 라우팅 테이블을 별도의 네트워크로 수정한다는 사실을 알게 되었습니다.

라우팅 테이블

간단히 말해서 이것은 Linux가 통과하려는 주소가 무엇으로 시작되어야 하는지를 포함하는 첫 번째 열의 테이블이고, 이 주소에서 통과할 네트워크 어댑터가 두 번째 열에 있는 테이블입니다. 실제로 더 많은 스피커가 있지만 이것이 본질을 바꾸지는 않습니다.

라우팅 테이블을 보려면 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 

여기서 각 줄은 특정 주소로 메시지를 보내기 위해 어디로 가야 하는지를 담당합니다. 첫 번째는 주소가 시작되어야 하는 위치에 대한 설명입니다. 192.168.0.0/16이 주소가 192.168로 시작해야 함을 의미하는지 확인하려면 IP 주소 마스크가 무엇인지 Google에 검색해야 합니다. dev 뒤에는 메시지를 보내야 하는 어댑터의 이름이 있습니다.

VPN의 경우 Linux는 가상 어댑터인 tun0을 만들었습니다. 이 라인은 192.168로 시작하는 모든 주소에 대한 트래픽이 이를 통과하도록 보장합니다.

192.168.0.0/16 dev tun0 scope link 

다음 명령을 사용하여 라우팅 테이블의 현재 상태를 확인할 수도 있습니다. 노선 -n (IP 주소는 교묘하게 익명화됩니다.) 이 명령은 다른 형식으로 결과를 생성하며 일반적으로 더 이상 사용되지 않습니다. 그러나 해당 출력은 종종 인터넷 매뉴얼에서 발견되므로 읽을 수 있어야 합니다.

경로의 IP 주소가 시작되어야 하는 위치는 대상 및 Genmask 열의 조합으로 이해할 수 있습니다. Genmask의 숫자 255에 해당하는 IP 주소 부분은 고려되지만 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

VPN-Slice 없이 openconnect를 호출한 후 다음과 같이 되었습니다.

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

그리고 이렇게 VPN-Slice와 결합하여 openconnect를 호출한 후

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 설정 방법을 이해하는 데는 이 후기가 충분할 것입니다. 하지만 무엇을 어떻게 해야 하는지 이해하려고 노력하는 동안 저자에게는 효과가 있지만 어떤 이유로 나에게는 효과가 없는 가이드를 많이 읽었고, 내가 찾은 모든 부분을 여기에 추가하기로 결정했습니다. 나는 그런 일에 매우 기뻐할 것입니다.

출처 : habr.com