Doriți să utilizați Linux la serviciu, dar VPN-ul corporativ nu vă permite? Atunci acest articol ar putea fi de ajutor, deși nu este sigur. Vreau să avertizez dinainte că nu înțeleg foarte bine problemele de administrare a rețelelor, așa că nu exclud posibilitatea că am făcut totul greșit. Pe de altă parte, nu este exclus să reușesc să scriu un ghid care să fie înțeles de oameni obișnuiți, așa că vă sfătuiesc să încercați.
Articolul conține multe informații inutile, dar fără aceste cunoștințe nu aș fi reușit să rezolv problemele care au apărut neașteptat la configurarea VPN-ului. Cred că oricine va încerca să aplice acest ghid va avea probleme pe care eu nu le-am întâmpinat și sper că aceste informații inutile le vor ajuta să le rezolve singuri.
Cele mai multe comenzi utilizate în ghid trebuie executate prin sudo, care pentru scurtimea explicării a fost omis. Țineți cont de acest lucru.
Cele mai multe adrese IP au fost obfuscate sever, așa că dacă vedeți o adresă de tipul 435.435.435.435 – acolo ar trebui să fie o adresă IP normală, specifică pentru cazul dumneavoastră.
Am Ubuntu 18.04, dar cred că cu câteva ajustări ghidul poate fi aplicat și altor distribuții. Totuși, în acest text Linux == Ubuntu.
Cisco Connect
Cei care folosesc Windows sau MacOS pot să se conecteze la VPN-ul nostru corporativ prin Cisco Connect, căruia trebuie să-i specificați adresa gateway-ului și să introduceți, la fiecare conectare, o parolă formată dintr-o parte fixă și un cod generat de Google Authenticator.
În cazul Linux-ului, nu am reușit să instalez Cisco Connect, dar am găsit recomandarea de a folosi openconnect, creat special pentru a înlocui Cisco Connect.
Openconnect
Teoretic, în Ubuntu există o interfață grafică specială pentru openconnect, dar la mine nu a funcționat. Poate că a fost mai bine așa.
În Ubuntu, openconnect se instalează din managerul de pachete.
apt install openconnectImediat după instalare, puteți încerca să vă conectați la VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com este adresa unui VPN fictiv
poxvuibr – este numele unui utilizator fictiv
openconnect va solicita introducerea unei parole, care, să aduc aminte, constă dintr-o parte fixă și un cod din Google Authenticator, apoi va încerca să se conecteze la vpn. Dacă a reușit, felicitări, puteți sări cu încredere peste mijlocul în care sunt multe dificultăți și să treceți la secțiunea despre funcționarea openconnect în fundal. Dacă nu a funcționat, puteți continua. Totuși, dacă a reușit să se conecteze, de exemplu, de pe un Wi-Fi public la locul de muncă, atunci poate fi o bucurie prematură; trebuie să încercați să repetați procedura de acasă.
Certificat
Cu o mare probabilitate, nimic nu se va lansa, iar ieșirea lui openconnect va arăta cam așa:
POST https://vpn.evilcorp.com/
Conectat la 777.777.777.777:443
Negociere SSL cu vpn.evilcorp.com
Verificarea certificatului serverului a eșuat: semnatarul nu a fost găsit
Certificatul de la serverul VPN "vpn.evilcorp.com" a eșuat la verificare.
Motiv: semnatarul nu a fost găsit
Pentru a avea încredere în acest server în viitor, adăugați poate asta la linia dumneavoastră de comandă:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Introduceți 'yes' pentru a accepta, 'no' pentru a anula; orice altceva pentru a vizualiza: fgets (stdin): Operațiune în curs de desfășurarePe de o parte, este neplăcut, pentru că nu s-a realizat conexiunea la VPN, dar pe de altă parte, cum să corectăm această problemă este în principiu clar.
Aici serverul ne-a trimis un certificat, din care putem determina că conexiunea se face către serverul corporației noastre, nu către un fraudator, dar sistemul nu cunoaște acest certificat. Din acest motiv, acesta nu poate verifica dacă serverul este autentic sau nu, și din precauție întrerupe funcționarea.
Pentru ca openconnect să se conecteze la server, trebuie să-i spunem explicit ce certificat ar trebui să vină de la serverul VPN, folosind cheia —servercert
Și pentru a afla ce certificat ne-a trimis serverul, putem lua direct din ceea ce a tipărit openconnect. Iată din acest fragment:
Pentru a avea încredere în acest server în viitor, adăugați poate asta la linia dumneavoastră de comandă:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Introduceți 'yes' pentru a accepta, 'no' pentru a anula; orice altceva pentru a vizualiza: fgets (stdin): Operațiune în curs de desfășurareAceastă comandă poate fi utilizată pentru a încerca să ne conectăm din nou
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comPoate acum a funcționat, atunci putem trece la final. Dar personal, Ubuntu mi-a arătat o dezaprobată într-o astfel de formă.
POST https://vpn.evilcorp.com/
Conectat la 777.777.777.777:443
Negocierea SSL cu vpn.evilcorp.com
Verificarea certificatului serverului a eșuat: semnatar nu găsit
Conectat la HTTPS pe vpn.evilcorp.com
XML POST activat
Vă rugăm să introduceți numele de utilizator și parola.
POST https://vpn.evilcorp.com/
Am primit răspuns CONNECT: HTTP/1.1 200 OK
CSTP conectat. DPD 300, Keepalive 30
Configurarea DTLS a eșuat; folosind SSL în schimb
Conectat ca 192.168.333.222, folosind SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
Răspunsuri RTNETLINK: Fișierul există
/etc/resolvconf/update.d/libc: Avertizare: /etc/resolv.conf nu este un link simbolic către /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 va putea fi accesat. Adresele de tip jira.evilcorp.com nu se rezolvă deloc.
Ce s-a întâmplat aici, nu înțeleg. Dar experimentul arată că, dacă adăugăm în /etc/resolv.conf linia
nameserver 192.168.430.534atunci adresele din interiorul VPN-ului vor începe să se rezolve în mod magic și putem naviga pe ele, ceea ce înseamnă că, ceea ce caută DNS pentru a rezolva adresele, se uită exact în /etc/resolv.conf și nu în altă parte.
Că conexiunea la VPN există și funcționează, se poate verifica și fără modificări în /etc/resolv.conf, este suficient să introduci în browser un nume de resursă din vpn, ci adresa sa IP
În final, rezultă două probleme
- când te conectezi la VPN, DNS-ul acestuia nu este preluat
- tot traficul trece prin vpn, care nu permite accesul la internet
Ce să faci, vă voi spune acum, dar mai întâi puțină automatizare.
Introducerea automată a părții fixe a parolei
Până în prezent, probabil că ai introdus parola de cel puțin cinci ori și această procedură te-a obosit considerabil. În primul rând, pentru că parola este lungă, în al doilea rând, pentru că la introducere trebuie să te încadrezi într-un interval de timp fix
Soluția finală a problemei nu a fost inclusă în articol, dar se poate face astfel încât partea fixă a parolei să nu trebuiască introdusă de prea multe ori.
Să presupunem că partea fixă a parolei este — fixedPassword, iar partea din Google Authenticator 567 987. Întreaga parolă openconnect poate fi transmisă prin standard input folosind argumentul —passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinAcum poți reveni constant la ultima comandă introdusă și schimba doar partea din Google Authenticator.
VPN-ul corporativ nu permite accesul la internet.
Este destul de incomod când, pentru a accesa habr, trebuie să folosești un computer separat. Absența posibilității de a copia și lipi de pe stackoverflow poate paraliza complet munca, de aceea trebuie să facem ceva.
Trebuie să ne organizăm cumva, astfel încât atunci când trebuie să accesăm resursa din rețeaua internă, Linux să folosească VPN, iar când trebuie să accesăm Habr — să folosească internetul.
Openconnect, după ce se lansează și stabilește conexiunea cu VPN, execută un script special care se află în /usr/share/vpnc-scripts/vpnc-script. La script se transmit anumite variabile, iar acesta configurează VPN-ul. Din păcate, nu am reușit să înțeleg cum să separ traficul între VPN-ul corporativ și restul internetului folosind scriptul standard.
Se pare că special pentru persoanele ca mine a fost dezvoltată utilitatea vpn-slice, care permite direcționarea traficului pe două canale fără a face prea multe manevre. Adică, va trebui să facem manevre, dar nu e nevoie să fim șamani.
Separarea traficului folosind vpn-slice
În primul rând, va trebui să instalăm vpn-slice, iar cu asta va trebui să ne descurcăm singuri. Dacă în comentarii apar întrebări, voi scrie un post separat pe această temă. Dar este un program obișnuit pe Python, așa că nu ar trebui să fie dificultăți. L-am instalat folosind virtualenv.
Apoi, utilitatea trebuie aplicată, folosind cheia —script pentru a specifica openconnect, astfel încât în loc de scriptul standard să folosească 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 În —script se transmite un șir cu comanda care trebuie invocată în locul scriptului. \.\/bin\/vpn-slice — calea către fișierul executabil vpn-slice 192.168.430.0\/24 — masca adreselor pe care trebuie să le acceseze VPN-ul. Aici, se înțelege că, dacă adresa începe cu 192.168.430, atunci resursa cu această adresă trebuie căutată în interiorul VPN.
Acum situația ar trebui să fie aproape normală. Aproape. Acum se poate accesa Habr și se poate accesa resursa internă pe IP, dar nu se poate accesa resursa internă după numele simbolic. Dacă se scrie corespondența între numele simbolic și adresă în hosts — totul ar trebui să funcționeze. Și să funcționeze, până când IP-ul se schimbă. Linux acum știe să acceseze internetul sau rețeaua internă în funcție de IP. Dar pentru a determina adresa se folosește în continuare un DNS non-corporativ.
Problema poate apărea și sub această formă — la lucru totul este în regulă, dar acasă, resursele interne pot fi accesate doar prin IP. Acest lucru se întâmplă deoarece atunci când ești conectat la Wi-Fi-ul corporativ, DNS-ul utilizat este tot corporativ, iar adresele simbolice din VPN sunt rezolvate, deși nu poți accesa o astfel de adresă fără a folosi VPN.
Modificare automată a fișierului hosts
Dacă vpn-slice este rugat politicos, el poate, după conectarea VPN, să acceseze DNS-ul său, să găsească adresele IP ale resurselor necesare în funcție de numele lor simbolice și să le scrie în hosts. După deconectarea VPN, aceste adrese vor fi șterse din hosts. Pentru aceasta, trebuie să transmiți numele simbolice în vpn-slice ca argumente. Așa.
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ă.
Caută adresele tuturor subdomeniilor în DNS-ul oferit de VPN
Dacă sunt puține adrese în rețea, abordarea cu modificarea automată a fișierului hosts funcționează bine. Dar dacă sunt multe resurse în rețea, va trebui să adaugi constant în script linii precum zoidberg.test.evilcorp.com, deoarece Zoidberg este numele unuia dintre standurile de testare.
Dar acum, când avem o înțelegere mai bună a lucrurilor, putem elimina această necesitate.
Dacă după conectarea la VPN verifici în \/etc\/hosts, poți vedea o astfel de linie
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
De asemenea, o nouă linie a fost adăugată în resolv.conf. Pe scurt, vpn-slice a reușit cumva să determine unde se află serverul DNS pentru VPN.
Acum trebuie să facem astfel încât, pentru a afla adresa IP a unui nume de domeniu care se încheie cu evilcorp.com, Linux să acceseze DNS-ul corporativ, iar dacă trebuie altceva, să meargă la cel implicit.
Am căutat destul de mult și am descoperit că această funcționalitate există în Ubuntu din cutie. Se referă la posibilitatea de a utiliza un server DNS local numit dnsmasq pentru rezolvarea numelui.
Adică, se poate face astfel încât Linux să consulte întotdeauna serverul DNS local pentru adrese IP, care, la rândul său, va căuta IP-urile pe servere DNS externe corespunzătoare, în funcție de numele de domeniu.
Pentru a gestiona tot ceea ce este legat de rețele și conexiuni de rețea în Ubuntu, se folosește NetworkManager, iar interfața grafică pentru selectarea, de exemplu, a unei conexiuni Wi-Fi, este pur și simplu un front pentru acesta.
Va trebui să ne uităm în configurațiile sale.
- Creează un fișier în /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Atenție la punctul din fața evilcorp. Acesta semnalează lui dnsmasq că toate subdomeniile evilcorp.com trebuie căutate în DNS-ul corporativ.
- Spune lui NetworkManager să folosească dnsmasq pentru rezolvarea numelui
Configurația network-manager se află în /etc/NetworkManager/NetworkManager.conf Trebuie să adaugi acolo:
[main]
dns=dnsmasq
- Repornește NetworkManager
service network-manager restartAcum, după conectarea la VPN folosind combinația openconnect și vpn-slice, IP-ul va fi determinat corect, chiar dacă nu se adaugă adrese simbolice ca argumente pentru vpnslice.
Cum să accesezi servicii prin VPN
După ce m-am conectat la VPN, am fost foarte încântat timp de două zile, dar apoi am descoperit că, dacă te conectezi la VPN din afara rețelei de birou, poșta nu funcționează. Simptom familiar, nu-i așa?
Poșta noastră se află la mail.publicevilcorp.com, deci nu se încadrează în regula din dnsmasq, iar adresa serverului de poștă este căutată prin DNS-ul public.
Dar în birou se folosește totuși DNS-ul în care această adresă există. Așa credeam. În realitate, după ce am adăugat în dnsmasq linia
address=/mail.publicevilcorp.com/192.168.430.534
situația nu s-a schimbat în niciun fel. IP-ul a rămas același. A trebuit să mă duc la birou.
Și abia mai târziu, când m-am aprofundat în situație și am încercat să dezleg problema, o persoană deșteaptă mi-a sugerat cum să o rezolv. Trebuia să mă conectez la serverul de poștă nu pur și simplu, ci prin VPN.
Folosesc vpn-slice pentru a accesa adresele care încep cu 192.168.430. Iar serverul de poștă nu doar că adresa sa simbolică nu este un subdomeniu evilcorp, dar nici IP-ul său nu începe cu 192.168.430. Și din rețeaua comună, evident, nu permite accesul nimănui.
Pentru ca Linux să acceseze VPN-ul și serverul de poștă, trebuie să-l adăugăm în vpn-slice și pe acesta. Să zicem că adresa serverului de poștă 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 activarea VPN-ului cu un singur argument
Desigur, toate acestea nu sunt foarte convenabile. Da, poți salva textul într-un fișier și să-l copiezi în consolă, în loc să-l scrii de mână, dar oricum nu este foarte plăcut. Pentru a ușura procesul, poți să înfășori comanda într-un script, care va fi situat în PATH. Apoi va trebui doar să introduci codul obținut din 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ă așezi scriptul în connect~evilcorp~, atunci poți scrie pur și simplu în consolă.
connect_evil_corp 567987Dar acum va trebui oricum să ținem consola în care rulează openconnect deschisă pentru ceva.
Rularea openconnect în fundal.
Din fericire, autorii openconnect au avut grijă de noi și au adăugat în program o opțiune specială —background, care face ca programul după lansare să funcționeze în fundal. Dacă o lansezi în acest fel, consolă poate fi închisă după pornire.
#!/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 doar nu este clar unde se duc jurnalele. Jurnalele nu ne sunt foarte necesare, dar cine știe. Openconnect poate să le redirecționeze în syslog, unde vor fi păstrate în siguranță. Trebuie să adăugăm cheia —syslog în comanda noastră.
#!/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 astfel, se dovedește că openconnect funcționează undeva acolo în fundal și nu deranjează pe nimeni, dar nu este clar cum să-l oprești. Adică, poți, desigur, să filtrezi ieșirea cu ps grep și să cauți procesul în al cărui nume apare openconnect, dar este cam obositor. Mulțumim autorilor care s-au gândit și la asta. În openconnect există o cheie —pid-file, cu ajutorul căreia poți instrui openconnect să scrie identificatorul procesului său î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 să omori procesul oricând cu comanda.
kill $(cat ~/vpn-pid)Dacă procesul nu există, kill va afișa o eroare, dar nu va arunca o excepție. Dacă fișierul nu există, nu se va întâmpla nimic grav, așa că poți omorî liniștit procesul în 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 poți porni computerul, deschide consola și lansează comanda, transmitându-i codul din Google Authenticator. Consola poate fi apoi închisă.
Fără vpn-slice. În loc de postfață.
A fost foarte dificil să înțeleg cum să trăiesc fără vpn-slice. A trebuit să citesc mult și să caut pe Google. Din fericire, după ce am petrecut atât de mult timp cu problema, manualele tehnice și chiar man openconnect se citesc ca romane captivante.
În final, am aflat că vpn-slice, la fel ca scriptul original, modifică tabela de rutare pentru a diviza rețelele.
Tabela de rutare
Asta, pe scurt, este o tabelă în care prima coloană conține de la ce ar trebui să înceapă adresa pe care Linux vrea să o acceseze, iar a doua prin ce adaptor de rețea ar trebui să treacă acea adresă. În realitate, sunt mai multe coloane, dar esența nu se schimbă.
Pentru a vizualiza tabela de rutare, trebuie să execuț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 corespunde locatiei pe care trebuie să o parcurgă pentru a trimite un mesaj la o anumită adresă. Prima descrie de la ce ar trebui să înceapă adresa. Pentru a înțelege cum să determinăm că 192.168.0.0/16 înseamnă că adresa trebuie să înceapă cu 192.168, trebuie să căutăm ce este o mască de adresă IP. După dev se află numele adaptorului prin care trebuie să trimitem mesajul.
Pentru VPN, Linux a creat un adaptor virtual — tun0. Linia care se ocupă de traficul pentru toate adresele care încep cu 192.168 este
192.168.0.0/16 dev tun0 scope link De asemenea, pentru a verifica starea curentă a tabelei de rutare, poți folosi comanda route -n (adresele IP sunt talentat anonimizate) Această comandă oferă rezultate într-o formă diferită și este de fapt deprecated, dar ieșirea ei apare frecvent în manualele de pe internet și trebuie să știm să o citim.
De unde ar trebui să înceapă o adresă IP pentru rută poate fi înțeles din combinația coloanelor Destination și Genmask. Acele părți ale adresei IP pentru care în Genmask sunt numerele 255 sunt luate în considerare, iar cele unde sunt 0 — nu. Așadar, combinația Destination 192.168.0.0 și Genmask 255.255.255.0 înseamnă că dacă adresa începe cu 192.168.0, atunci cererea pentru ea va merge prin această rută. Dacă Destination este 192.168.0.0, dar Genmask este 255.255.0.0, atunci prin această rută vor merge cererile pentru adresele care încep cu 192.168.
Pentru a înțelege ce face de fapt vpn-slice, am decis să compar stările tabelelor înainte și după
Înainte de activarea VPN-ului era 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ă apelarea openconnect fără vpn-slice a devenit așa
route -n
Tabloul de rutare IP al kernel-ului
Destinație 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ă apelul openconnect în combinație cu vpn-slice, arată așa
Tabloul de rutare IP al kernel-ului
Destinație 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 observă că, dacă nu se folosește vpn-slice, openconnect scrie în mod explicit că pentru toate adresele, în afară de cele specificate separatamente, trebuie să se meargă prin vpn.
Aici:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Acolo este menționat imediat încă un drum care trebuie folosit dacă adresa pe care încearcă să o acceseze Linux nu corespunde niciunei măști din tabel.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Aici este deja scris că în acest caz trebuie să se meargă prin adaptorul standard Wi-Fi.
Cred că drumul pentru VPN este folosit pentru că este primul în tabelul de rutare.
Și teoretic, dacă se elimină această cale implicită din tabelul de rutare, openconnect ar trebui să asigure o funcționare normală în combinație cu dnsmasq.
Am încercat
route del defaultȘi totul a mers bine.
Routarea cererilor către serverul de mail fără vpn-slice
Dar mai am și un server de mail cu adresa 555.555.555.555, la care trebuie să se ajungă tot prin vpn. Trasa către el trebuie adăugată manual.
ip route add 555.555.555.555 via dev tun0Și acum totul este bine. Așa că se poate trăi fără vpn-slice, dar trebuie să știi bine ce faci. Mă gândesc acum dacă să nu adaug în ultima linie a scriptului original openconnect eliminarea rutei implicite și adăugarea rutei pentru serverul de mail după conectarea la vpn, doar pentru a reduce părțile mobile din bicicleta mea.
Probabil că pentru unii, pentru a înțelege cum să configurezi un VPN, acest epilog ar fi fost suficient. Dar eu, î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 dintr-un motiv oarecare nu funcționează pentru mine și am decis să adaug aici toate fragmentele pe care le-am găsit. M-aș fi bucurat foarte mult de ceva de genul acesta.
Sursa: habr.com
