Doriți să utilizați Linux la serviciu, dar VPN-ul dvs. corporativ nu vă permite? Atunci acest articol poate ajuta, deși acest lucru nu este sigur. Aș dori să vă avertizez din timp că nu înțeleg bine problemele de administrare a rețelei, așa că este posibil să fi făcut totul greșit. Pe de altă parte, este posibil să pot scrie un ghid în așa fel încât să fie de înțeles oamenilor obișnuiți, așa că vă sfătuiesc să îl încercați.
Articolul conține o mulțime de informații inutile, dar fără aceste cunoștințe nu aș fi putut rezolva problemele care mi-au apărut în mod neașteptat la configurarea unui VPN. Cred că oricine va încerca să folosească acest ghid va avea probleme pe care eu nu le-am avut și sper că aceste informații suplimentare vor ajuta la rezolvarea singura a acestor probleme.
Majoritatea comenzilor utilizate în acest ghid trebuie să fie executate prin sudo, care a fost eliminat pentru concizie. Ține minte.
Majoritatea adreselor IP au fost sever ascunse, așa că dacă vedeți o adresă precum 435.435.435.435, trebuie să existe o adresă IP normală acolo, specifică cazului dvs.
Am Ubuntu 18.04, dar cred că, cu modificări minore, ghidul poate fi aplicat și altor distribuții. Cu toate acestea, în acest text Linux == Ubuntu.
Cisco Connect
Cei care sunt pe Windows sau MacOS se pot conecta la VPN-ul nostru corporativ prin Cisco Connect, care trebuie să specifice adresa gateway-ului și, de fiecare dată când vă conectați, să introduceți o parolă formată dintr-o parte fixă și un cod generat de Google Authenticator.
În cazul Linux, nu am putut pune Cisco Connect să ruleze, dar am reușit să caut pe Google o recomandare de a folosi openconnect, făcută special pentru a înlocui Cisco Connect.
Openconnect
În teorie, Ubuntu are o interfață grafică specială pentru openconnect, dar nu a funcționat pentru mine. Poate că e în bine.
Pe Ubuntu, openconnect este instalat din managerul de pachete.
apt install openconnectImediat după instalare, puteți încerca să vă conectați la un VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com este adresa unui VPN fictiv
poxvuibr - nume de utilizator fictiv
openconnect vă va cere să introduceți o parolă, care, permiteți-mi să vă reamintesc, constă dintr-o parte fixă și un cod de la Google Authenticator, iar apoi va încerca să se conecteze la vpn. Dacă funcționează, felicitări, puteți sări în siguranță pe mijloc, care este multă durere, și să treceți la punctul despre rularea openconnect în fundal. Dacă nu funcționează, atunci poți continua. Deși, dacă a funcționat atunci când vă conectați, de exemplu, de la un Wi-Fi pentru oaspeți la serviciu, atunci poate fi prea devreme pentru a vă bucura; ar trebui să încercați să repetați procedura de acasă.
certificat
Există o probabilitate mare ca nimic să nu pornească, iar ieșirea openconnect va arăta cam așa:
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 progressPe de o parte, acest lucru este neplăcut, deoarece nu a existat nicio conexiune la VPN, dar, pe de altă parte, cum să remediați această problemă este, în principiu, clar.
Aici serverul ne-a trimis un certificat, prin care putem stabili că conexiunea se face la serverul corporației noastre native și nu la un fraudator rău, iar acest certificat este necunoscut de sistem. Și, prin urmare, nu poate verifica dacă serverul este real sau nu. Și așa, pentru orice eventualitate, nu mai funcționează.
Pentru ca openconnect să se conecteze la server, trebuie să îi spuneți în mod explicit ce certificat ar trebui să provină de la serverul VPN folosind cheia —servercert
Și puteți afla ce certificat ne-a trimis serverul direct din ce a tipărit openconnect. Iată din această piesă:
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 progressCu această comandă puteți încerca să vă conectați din nou
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comPoate că acum funcționează, apoi poți trece la final. Dar personal, Ubunta mi-a arătat o smochină sub această formă
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.comhabr.com se va rezolva, dar nu veți putea merge acolo. Adresele precum jira.evilcorp.com nu sunt rezolvate deloc.
Ce s-a întâmplat aici nu îmi este clar. Dar experimentul arată că dacă adăugați linia în /etc/resolv.conf
nameserver 192.168.430.534atunci adresele din interiorul VPN vor începe să se rezolve magic și puteți trece prin ele, adică ceea ce caută DNS pentru a rezolva adresele arată în mod specific în /etc/resolv.conf și nu în altă parte.
Puteți verifica dacă există o conexiune la VPN și funcționează fără a face nicio modificare în /etc/resolv.conf; pentru a face acest lucru, trebuie doar să introduceți în browser nu numele simbolic al resursei din VPN, ci adresa IP a acesteia.
Ca urmare, există două probleme
- Când vă conectați la un VPN, dn-ul acestuia nu este preluat
- tot traficul trece prin VPN, care nu permite accesul la Internet
Îți voi spune ce să faci acum, dar mai întâi puțină automatizare.
Introducerea automată a părții fixe a parolei
Până acum, cel mai probabil ați introdus deja parola de cel puțin cinci ori și această procedură v-a obosit deja. În primul rând, pentru că parola este lungă și, în al doilea rând, pentru că atunci când intri trebuie să te încadrezi într-o perioadă de timp fixă
Soluția finală a problemei nu a fost inclusă în articol, dar vă puteți asigura că partea fixă a parolei nu trebuie să fie introdusă de mai multe ori.
Să presupunem că partea fixă a parolei este fixedPassword, iar partea de la Google Authenticator este 567. Întreaga parolă poate fi transmisă la openconnect prin intrarea standard folosind argumentul --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinAcum puteți reveni constant la ultima comandă introdusă și puteți schimba acolo doar o parte din Google Authenticator.
Un VPN corporativ nu vă permite să navigați pe internet.
În general, nu este foarte incomod când trebuie să folosiți un computer separat pentru a merge la Habr. Incapacitatea de a copia și lipi din stackoverfow poate paraliza în general munca, așa că trebuie făcut ceva.
Trebuie să-l organizăm cumva, astfel încât atunci când trebuie să accesezi o resursă din rețeaua internă, Linux să treacă la VPN, iar când trebuie să mergi la Habr, să treacă pe Internet.
openconnect, după lansarea și stabilirea unei conexiuni cu vpn, execută un script special, care se află în /usr/share/vpnc-scripts/vpnc-script. Unele variabile sunt transmise scriptului ca intrare și configurează VPN-ul. Din păcate, nu mi-am putut da seama cum să împart fluxurile de trafic între un VPN corporativ și restul internetului folosind un script nativ.
Aparent, utilitarul vpn-slice a fost dezvoltat special pentru oameni ca mine, care vă permite să trimiteți trafic prin două canale fără să dansați cu tamburina. Ei bine, adică va trebui să dansezi, dar nu trebuie să fii șaman.
Separarea traficului folosind vpn-slice
În primul rând, va trebui să instalați vpn-slice, va trebui să vă dați seama singur. Dacă există întrebări în comentarii, voi scrie o postare separată despre asta. Dar acesta este un program obișnuit Python, deci nu ar trebui să existe dificultăți. Am instalat folosind virtualenv.
Și apoi utilitarul trebuie aplicat, folosind comutatorul -script, indicând pentru a deschide conectarea că în loc de script-ul standard, trebuie să utilizați 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 primește un șir cu o comandă care trebuie apelată în locul scriptului. ./bin/vpn-slice - calea către fișierul executabil vpn-slice 192.168.430.0/24 - masca adreselor la care să mergeți în vpn. Aici, ne referim că dacă adresa începe cu 192.168.430, atunci resursa cu această adresă trebuie căutată în interiorul VPN-ului
Situația ar trebui să fie acum aproape normală. Aproape. Acum poți să mergi la Habr și poți să mergi la resursa intra-corporativă prin ip, dar nu poți să mergi la resursa intra-corporativă prin nume simbolic. Dacă specificați o potrivire între numele simbolic și adresa din gazde, totul ar trebui să funcționeze. Și lucrează până se schimbă ip-ul. Linux poate accesa acum internetul sau intranetul, în funcție de IP. Dar DNS non-corporate este încă folosit pentru a determina adresa.
Problema se poate manifesta și sub această formă - la locul de muncă totul este în regulă, dar acasă puteți accesa doar resurse interne ale companiei prin IP. Acest lucru se datorează faptului că atunci când sunteți conectat la Wi-Fi corporativ, este utilizat și DNS-ul corporativ, iar adresele simbolice din VPN sunt rezolvate în acesta, în ciuda faptului că este încă imposibil să mergeți la o astfel de adresă fără a utiliza un VPN.
Modificarea automată a fișierului hosts
Dacă vpn-slice este întrebat politicos, atunci după ce a ridicat VPN-ul, poate merge la DNS-ul său, poate găsi acolo adresele IP ale resurselor necesare după numele lor simbolice și le poate introduce în gazde. După oprirea VPN-ului, aceste adrese vor fi eliminate din gazde. Pentru a face acest lucru, trebuie să transmiteți nume simbolice către vpn-slice ca argumente. Ca aceasta.
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 Acum totul ar trebui să funcționeze atât la birou, cât și pe plajă.
Căutați adresele tuturor subdomeniilor din DNS-ul dat de VPN
Dacă există puține adrese în rețea, atunci abordarea de modificare automată a fișierului hosts funcționează destul de bine. Dar dacă există o mulțime de resurse în rețea, atunci va trebui să adăugați în mod constant linii precum zoidberg.test.evilcorp.com la scriptul zoidberg este numele unuia dintre bancurile de testare.
Dar acum că înțelegem puțin de ce această nevoie poate fi eliminată.
Dacă, după ce ați ridicat VPN-ul, vă uitați în /etc/hosts, puteți vedea această linie
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREAT
Și o nouă linie a fost adăugată la resolv.conf. Pe scurt, vpn-slice a determinat cumva unde se află serverul dns pentru vpn.
Acum trebuie să ne asigurăm că, pentru a afla adresa IP a unui nume de domeniu care se termină în evilcorp.com, Linux merge la DNS-ul corporativ, iar dacă este nevoie de altceva, atunci la cel implicit.
Am căutat destul de mult timp pe Google și am descoperit că o astfel de funcționalitate este disponibilă imediat în Ubuntu. Aceasta înseamnă capacitatea de a utiliza serverul DNS local dnsmasq pentru a rezolva numele.
Adică, vă puteți asigura că Linux merge întotdeauna la serverul DNS local pentru adrese IP, care la rândul său, în funcție de numele domeniului, va căuta IP-ul pe serverul DNS extern corespunzător.
Pentru a gestiona tot ceea ce este legat de rețele și conexiunile de rețea, Ubuntu folosește NetworkManager, iar interfața grafică pentru selectarea, de exemplu, conexiunile Wi-Fi este doar un front-end al acesteia.
Va trebui să urcăm în configurația sa.
- Creați un fișier în /etc/NetworkManager/dnsmasq.d/evilcorp
adresa=/.evilcorp.com/192.168.430.534
Fiți atenți la punctul din fața evilcorp. Semnalează dnsmasq că toate subdomeniile evilcorp.com ar trebui căutate în dns-ul corporativ.
- Spuneți NetworkManager să folosească dnsmasq pentru rezolvarea numelor
Configurația managerului de rețea se află în /etc/NetworkManager/NetworkManager.conf Trebuie să adăugați acolo:
[main] dns=dnsmasq
- Reporniți NetworkManager
service network-manager restartAcum, după conectarea la un VPN folosind openconnect și vpn-slice, ip-ul va fi determinat în mod normal, chiar dacă nu adăugați adrese simbolice la argumentele la vpnslice.
Cum să accesați serviciile individuale prin VPN
După ce am reușit să mă conectez la VPN, am fost foarte fericit timp de două zile și apoi s-a dovedit că dacă mă conectez la VPN din afara rețelei de birou, atunci e-mailul nu funcționează. Simptomul este familiar, nu-i așa?
Poșta noastră se află în mail.publicevilcorp.com, ceea ce înseamnă că nu se încadrează sub regula din dnsmasq și adresa serverului de e-mail este căutată prin DNS public.
Ei bine, biroul folosește în continuare DNS, care conține această adresă. Asta am crezut eu. De fapt, după adăugarea liniei la dnsmasq
adresa=/mail.publicevilcorp.com/192.168.430.534
situația nu s-a schimbat deloc. ip a ramas acelasi. A trebuit să merg la muncă.
Și abia mai târziu, când am aprofundat situația și am înțeles puțin problema, o persoană deșteaptă mi-a spus cum să o rezolv. A fost necesar să se conecteze la serverul de e-mail nu doar așa, ci prin VPN
Folosesc vpn-slice pentru a trece prin VPN la adrese care încep cu 192.168.430. Iar serverul de e-mail nu numai că are o adresă simbolică care nu este un subdomeniu al evilcorp, ci nici nu are o adresă IP care începe cu 192.168.430. Și, desigur, nu permite nimănui din rețeaua generală să vină la el.
Pentru ca Linux să treacă prin VPN și către serverul de e-mail, trebuie să îl adăugați și la vpn-slice. Să presupunem că adresa expeditorului este 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 Script pentru ridicarea VPN cu un singur argument
Toate acestea, desigur, nu sunt foarte convenabile. Da, puteți salva textul într-un fișier și îl puteți copia și lipi în consolă în loc să-l tastați manual, dar încă nu este foarte plăcut. Pentru a ușura procesul, puteți împacheta comanda într-un script care va fi localizat în PATH. Și apoi va trebui doar să introduceți codul primit de la 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 Dacă puneți scriptul în connect~evilcorp~ puteți scrie pur și simplu în consolă
connect_evil_corp 567987Dar acum trebuie să păstrați deschisă consola în care rulează openconnect dintr-un motiv oarecare
Rulează openconnect în fundal
Din fericire, autorii openconnect au avut grijă de noi și au adăugat o cheie specială programului -background, care face ca programul să funcționeze în fundal după lansare. Dacă îl rulați astfel, puteți închide consola după lansare
#!/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 Acum pur și simplu nu este clar unde se duc jurnalele. În general, nu avem nevoie de jurnale, dar nu se știe niciodată. openconnect le poate redirecționa către syslog, unde vor fi păstrate în siguranță. trebuie să adăugați comutatorul –syslog la comandă
#!/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 Și așa, se dovedește că openconnect funcționează undeva în fundal și nu deranjează pe nimeni, dar nu este clar cum să-l oprească. Adică, puteți, desigur, să filtrați ieșirea ps folosind grep și să căutați un proces al cărui nume conține openconnect, dar acest lucru este oarecum plictisitor. Mulțumim autorilor care s-au gândit și la asta. Openconnect are o cheie -pid-file, cu ajutorul căreia îi puteți instrui openconnect să scrie identificatorul de proces într-un fișier.
#!/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-pidAcum poți oricând să omorâți un proces cu comanda
kill $(cat ~/vpn-pid)Dacă nu există niciun proces, kill va blestema, dar nu va arunca o eroare. Dacă fișierul nu este acolo, atunci nu se va întâmpla nimic rău, așa că puteți opri în siguranță procesul din prima linie a scriptului.
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-pidAcum puteți porni computerul, deschide consola și executa comanda, transmițându-i codul de la Google Authenticator. Consola poate fi apoi fixată în cuie.
Fără VPN-slice. În loc de postfață
S-a dovedit a fi foarte greu de înțeles cum să trăiești fără VPN-slice. A trebuit să citesc și să caut mult pe google. Din fericire, după ce au petrecut atât de mult timp cu o problemă, manualele tehnice și chiar Man Openconnect citesc ca niște romane interesante.
Drept urmare, am aflat că vpn-slice, ca și scriptul nativ, modifică tabelul de rutare pentru a separa rețele.
Tabel de rutare
Pentru a spune simplu, acesta este un tabel din prima coloană care conține cu ce ar trebui să înceapă adresa pe care dorește să treacă Linux, iar în a doua coloană prin ce adaptor de rețea trebuie să treacă la această adresă. De fapt, sunt mai multe difuzoare, dar asta nu schimbă esența.
Pentru a vizualiza tabelul de rutare, trebuie să rulați comanda 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 Aici, fiecare linie este responsabilă de unde trebuie să mergeți pentru a trimite un mesaj la o anumită adresă. Prima este o descriere a locului în care ar trebui să înceapă adresa. Pentru a înțelege cum să determinați că 192.168.0.0/16 înseamnă că adresa ar trebui să înceapă cu 192.168, trebuie să căutați pe Google ce este o mască de adresă IP. După dev există numele adaptorului către care ar trebui să fie trimis mesajul.
Pentru VPN, Linux a creat un adaptor virtual - tun0. Linia asigură că traficul pentru toate adresele care încep cu 192.168 trece prin ea
192.168.0.0/16 dev tun0 scope link De asemenea, puteți privi starea curentă a tabelului de rutare folosind comanda traseu -n (Adresele IP sunt anonimizate inteligent) Această comandă produce rezultate într-o formă diferită și este în general depreciată, dar rezultatul ei se găsește adesea în manuale de pe Internet și trebuie să o poți citi.
Unde ar trebui să înceapă adresa IP pentru o rută poate fi înțeleasă din combinația dintre coloanele Destinație și Genmask. Sunt luate în considerare acele părți ale adresei IP care corespund numerelor 255 din Genmask, dar cele în care există 0 nu. Adică, combinația dintre Destinația 192.168.0.0 și Genmask 255.255.255.0 înseamnă că dacă adresa începe cu 192.168.0, atunci cererea către aceasta va merge pe această rută. Și dacă Destinația 192.168.0.0 dar Genmask 255.255.0.0, atunci solicitările către adrese care încep cu 192.168 vor merge pe această rută
Pentru a-mi da seama ce face de fapt vpn-slice, am decis să mă uit la stările tabelelor înainte și după
Înainte de a porni VPN-ul, a fost așa
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 wlp3s0După ce am apelat openconnect fără vpn-slice, a devenit așa
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Și după apelarea openconnect în combinație cu vpn-slice în felul acesta
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 tun0Se poate observa că, dacă nu utilizați vpn-slice, atunci openconnect scrie în mod explicit că toate adresele, cu excepția celor indicate în mod specific, trebuie accesate prin vpn.
Chiar aici:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Acolo, lângă ea, este imediat indicată o altă cale, care trebuie folosită dacă adresa prin care încearcă să o treacă Linux nu se potrivește cu nicio mască din tabel.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Este deja scris aici că în acest caz trebuie să utilizați un adaptor Wi-Fi standard.
Cred că calea VPN este folosită deoarece este prima din tabelul de rutare.
Și teoretic, dacă eliminați această cale implicită din tabelul de rutare, atunci împreună cu dnsmasq openconnect ar trebui să asigure funcționarea normală.
am incercat
route del defaultȘi totul a funcționat.
Dirijarea cererilor către un server de e-mail fără vpn-slice
Dar am și un server de mail cu adresa 555.555.555.555, care trebuie accesat și prin VPN. De asemenea, traseul către acesta trebuie adăugat manual.
ip route add 555.555.555.555 via dev tun0Și acum totul este bine. Deci te poți descurca fără vpn-slice, dar trebuie să știi bine ce faci. Acum mă gândesc să adaug la ultima linie a scriptului nativ openconnect eliminarea rutei implicite și să adaug o rută pentru mailer după conectarea la vpn, doar pentru a avea mai puține părți mobile în bicicleta mea.
Probabil, această postfață ar fi suficientă pentru ca cineva să înțeleagă cum să configureze un VPN. Dar în timp ce încercam să înțeleg ce și cum să fac, am citit destul de multe astfel de ghiduri care funcționează pentru autor, dar din anumite motive nu funcționează pentru mine și am decis să adaug aici toate piesele pe care le-am găsit. Aș fi foarte bucuros de așa ceva.
Sursa: www.habr.com