Chcete v práci používať Linux, no vaša firemná VPN vám to nedovolí? Potom môže pomôcť tento článok, aj keď to nie je isté. Vopred upozorňujem, že sa dobre nerozumiem problematike správy siete, takže je možné, že som urobil všetko zle. Na druhej strane je možné, že návod napíšem tak, že bude zrozumiteľný aj pre bežného človeka, preto vám radím, aby ste to vyskúšali.
Článok obsahuje množstvo zbytočných informácií, no bez týchto znalostí by som nedokázal vyriešiť problémy, ktoré sa mi nečakane objavili s nastavením VPN. Myslím si, že každý, kto sa pokúsi použiť túto príručku, bude mať problémy, ktoré som nemal ja, a dúfam, že tieto dodatočné informácie pomôžu vyriešiť tieto problémy samostatne.
Väčšinu príkazov použitých v tejto príručke je potrebné spustiť cez sudo, ktoré bolo kvôli stručnosti odstránené. Mysli na to.
Väčšina adries IP bola značne zahmlená, takže ak vidíte adresu ako 435.435.435.435, musí tam byť nejaká normálna adresa IP, špecifická pre váš prípad.
Mám Ubuntu 18.04, ale myslím si, že s malými zmenami je možné príručku použiť aj na iné distribúcie. V tomto texte však Linux == Ubuntu.
Cisco Connect
Tí, ktorí používajú Windows alebo MacOS, sa môžu pripojiť k našej firemnej VPN cez Cisco Connect, ktorá musí zadať adresu brány a pri každom pripojení zadať heslo pozostávajúce z pevnej časti a kódu vygenerovaného aplikáciou Google Authenticator.
V prípade Linuxu sa mi nepodarilo spustiť Cisco Connect, ale podarilo sa mi vygoogliť odporúčanie na použitie openconnect, vytvorené špeciálne na nahradenie Cisco Connect.
Openconnect
Teoreticky má Ubuntu špeciálne grafické rozhranie pre openconnect, ale mne to nefungovalo. Možno je to k lepšiemu.
Na Ubuntu je openconnect nainštalovaný zo správcu balíkov.
apt install openconnectIhneď po inštalácii sa môžete pokúsiť pripojiť k sieti VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com je adresa fiktívnej siete VPN
poxvuibr - fiktívne používateľské meno
openconnect vás požiada o zadanie hesla, ktoré, pripomínam, pozostáva z pevnej časti a kódu z Google Authenticator a následne sa pokúsi pripojiť k vpn. Ak to funguje, gratulujeme, môžete pokojne preskočiť stred, čo je veľká bolesť, a prejsť k bodu, že na pozadí beží openconnect. Ak to nefunguje, môžete pokračovať. Aj keď to fungovalo pri pripojení napríklad z hosťujúcej Wi-Fi v práci, potom je možno priskoro na radosť, mali by ste skúsiť postup zopakovať z domu.
certifikát
Je vysoká pravdepodobnosť, že sa nič nespustí a výstup openconnect bude vyzerať asi takto:
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 progressNa jednej strane je to nepríjemné, pretože nebolo pripojenie k VPN, ale na druhej strane, ako tento problém vyriešiť, je v zásade jasné.
Tu nám server poslal certifikát, podľa ktorého vieme určiť, že sa pripájame k serveru našej rodnej korporácie a nie k zlému podvodníkovi, pričom tento certifikát systém nepozná. A preto nemôže skontrolovať, či je server skutočný alebo nie. A tak pre každý prípad prestane fungovať.
Aby sa openconnect mohol pripojiť k serveru, musíte mu explicitne povedať, ktorý certifikát by mal pochádzať zo servera VPN pomocou kľúča —servercert
A aký certifikát nám server poslal, môžete zistiť priamo z toho, čo openconnect vytlačil. Tu je z tohto dielu:
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 progressPomocou tohto príkazu sa môžete pokúsiť znova pripojiť
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMožno to teraz funguje, potom môžete prejsť na koniec. Osobne mi ale Ubunta ukázala figu v tejto podobe
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 sa vyrieši, ale nebudete tam môcť ísť. Adresy ako jira.evilcorp.com nie sú vôbec vyriešené.
Čo sa tu stalo, mi nie je jasné. Ale experiment ukazuje, že ak pridáte riadok do /etc/resolv.conf
nameserver 192.168.430.534potom sa adresy vo vnútri VPN začnú magicky riešiť a môžete sa nimi prechádzať, to znamená, že to, čo DNS hľadá na riešenie adries, vyzerá konkrétne v /etc/resolv.conf a nie niekde inde.
Môžete overiť, či existuje pripojenie k VPN a funguje bez vykonania akýchkoľvek zmien v /etc/resolv.conf; Ak to chcete urobiť, do prehliadača zadajte nie symbolický názov zdroja z VPN, ale jeho IP adresu
V dôsledku toho existujú dva problémy
- Pri pripájaní k sieti VPN sa jej dns nezdvíha
- všetka prevádzka ide cez VPN, ktorá neumožňuje prístup na internet
Poviem vám, čo máte robiť teraz, ale najprv trochu automatizácie.
Automatické zadanie pevnej časti hesla
S najväčšou pravdepodobnosťou ste už zadali svoje heslo najmenej päťkrát a tento postup vás už unavuje. Jednak preto, že heslo je dlhé a jednak preto, že pri zadávaní sa musíte zmestiť do pevne stanoveného časového obdobia
Konečné riešenie problému nebolo v článku zahrnuté, ale môžete sa uistiť, že pevná časť hesla sa nemusí zadávať mnohokrát.
Predpokladajme, že pevná časť hesla je fixedPassword a časť z Google Authenticator je 567 987. Celé heslo je možné odovzdať openconnect cez štandardný vstup pomocou argumentu --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinTeraz sa môžete neustále vracať k poslednému zadanému príkazu a meniť tam iba časť aplikácie Google Authenticator.
Firemná sieť VPN vám neumožňuje surfovať po internete.
Vo všeobecnosti nie je veľmi nepohodlné, keď musíte na cestu do Habr použiť samostatný počítač. Neschopnosť kopírovať a prilepiť zo stackoverfow môže vo všeobecnosti paralyzovať prácu, takže treba niečo urobiť.
Musíme to nejako zorganizovať tak, že keď potrebujete pristupovať k zdroju z internej siete, Linux ide do VPN a keď potrebujete ísť do Habr, ide na internet.
openconnect po spustení a nadviazaní spojenia s vpn vykoná špeciálny skript, ktorý sa nachádza v /usr/share/vpnc-scripts/vpnc-script. Niektoré premenné sú odovzdané skriptu ako vstup a konfiguruje VPN. Bohužiaľ sa mi nepodarilo zistiť, ako rozdeliť toky prevádzky medzi podnikovú sieť VPN a zvyšok internetu pomocou natívneho skriptu.
Zdá sa, že pomôcka vpn-slice bola vyvinutá špeciálne pre ľudí, ako som ja, čo vám umožňuje posielať prevádzku cez dva kanály bez tanca s tamburínou. To znamená, že budete musieť tancovať, ale nemusíte byť šaman.
Oddelenie dopravy pomocou vpn-slice
Najprv budete musieť nainštalovať vpn-slice, na to budete musieť prísť sami. Ak sú v komentároch otázky, napíšem o tom samostatný príspevok. Ale toto je bežný Python program, takže by nemali byť žiadne problémy. Inštaloval som pomocou virtualenv.
Potom je potrebné použiť pomôcku pomocou prepínača -script, čo znamená, že pre openconnect musíte namiesto štandardného skriptu použ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 odovzdá reťazec s príkazom, ktorý je potrebné zavolať namiesto skriptu. ./bin/vpn-slice - cesta k spustiteľnému súboru vpn-slice 192.168.430.0/24 - maska adries, na ktoré sa má prejsť vo vpn. Tu máme na mysli, že ak adresa začína 192.168.430, zdroj s touto adresou je potrebné vyhľadať vo vnútri VPN
Teraz by mala byť situácia takmer normálna. Takmer. Teraz môžete prejsť na Habr a môžete prejsť na vnútropodnikový zdroj pomocou ip, ale nemôžete prejsť na vnútropodnikový zdroj podľa symbolického názvu. Ak zadáte zhodu medzi symbolickým názvom a adresou v hostiteľoch, všetko by malo fungovať. A pracuj, kým sa ip nezmení. Linux má teraz prístup na internet alebo intranet v závislosti od IP. Na určenie adresy sa však stále používa nepodnikový DNS.
Problém sa môže prejaviť aj v tejto podobe – v práci je všetko v poriadku, no doma sa k interným firemným zdrojom dostanete len cez IP. Pri pripojení na firemnú Wi-Fi sa totiž používa aj firemný DNS a v ňom sa riešia symbolické adresy z VPN napriek tomu, že bez použitia VPN sa na takú adresu stále nedá ísť.
Automatická úprava súboru hosts
Ak je vpn-slice požiadaný zdvorilo, potom po zvýšení VPN môže prejsť na svoj DNS, nájsť tam IP adresy potrebných zdrojov podľa ich symbolických názvov a zadať ich do hostiteľov. Po vypnutí VPN budú tieto adresy odstránené z hostiteľov. Aby ste to dosiahli, musíte do vpn-slice odovzdať symbolické názvy ako argumenty. Páči sa ti to.
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 Teraz by všetko malo fungovať v kancelárii aj na pláži.
Vyhľadajte adresy všetkých subdomén v DNS pridelenom VPN
Ak je v sieti málo adries, potom prístup automatickej úpravy súboru hosts funguje celkom dobre. Ale ak je v sieti veľa zdrojov, potom budete musieť neustále pridávať riadky ako zoidberg.test.evilcorp.com do skriptu zoidberg je názov jednej z testovacích staníc.
Ale teraz, keď už trochu rozumieme, prečo možno túto potrebu eliminovať.
Ak sa po zvýšení VPN pozriete do /etc/hosts, môžete vidieť tento riadok
192.168.430.534 0 0 0 dnsXNUMX.tunXNUMX # vpn-slice-tunXNUMX AUTOCREATED
A do resolv.conf bol pridaný nový riadok. Stručne povedané, vpn-slice nejako určil, kde sa nachádza server DNS pre vpn.
Teraz sa musíme uistiť, že na to, aby sme zistili IP adresu názvu domény končiacej na evilcorp.com, Linux ide na firemný DNS, a ak je potrebné niečo iné, tak na predvolený.
Googlil som dosť dlho a zistil som, že takáto funkcia je v Ubuntu dostupná hneď po vybalení. To znamená možnosť použiť lokálny server DNS dnsmasq na rozlíšenie názvov.
To znamená, že sa môžete uistiť, že Linux vždy prejde na lokálny server DNS pre adresy IP, ktorý zase v závislosti od názvu domény vyhľadá IP na príslušnom externom serveri DNS.
Na spravovanie všetkého, čo súvisí so sieťami a sieťovými pripojeniami, Ubuntu používa NetworkManager a grafické rozhranie na výber napríklad Wi-Fi pripojení je len jeho frontendom.
Budeme musieť stúpať v jeho konfigurácii.
- Vytvorte súbor v /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Venujte pozornosť bodu pred zlým zborom. Signalizuje dnsmasq, že všetky subdomény evilcorp.com by sa mali hľadať v podnikovom DNS.
- Povedzte NetworkManager, aby na rozlíšenie názvov použil dnsmasq
Konfigurácia správcu siete sa nachádza v /etc/NetworkManager/NetworkManager.conf Musíte tam pridať:
[main] dns=dnsmasq
- Reštartujte NetworkManager
service network-manager restartTeraz, po pripojení k VPN pomocou openconnect a vpn-slice, bude ip určená normálne, aj keď k argumentom vpnslice nepridáte symbolické adresy.
Ako pristupovať k jednotlivým službám cez VPN
Po tom, čo sa mi podarilo pripojiť k VPN, som sa dva dni veľmi tešil a potom sa ukázalo, že ak sa na VPN pripojím mimo kancelárskej siete, tak pošta nefunguje. Príznak je známy, však?
Naša pošta sa nachádza na adrese mail.publicevilcorp.com, čo znamená, že nespadá pod pravidlo dnsmasq a adresa poštového servera sa hľadá cez verejné DNS.
No úrad stále používa DNS, ktorý obsahuje túto adresu. To som si myslel. V skutočnosti po pridaní riadku do dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
situácia sa vôbec nezmenila. ip zostala rovnaká. Musel som ísť do práce.
A až neskôr, keď som sa hlbšie ponoril do situácie a trochu pochopil problém, mi jeden šikovný človek povedal, ako to vyriešiť. K poštovému serveru bolo potrebné pripojiť sa nielen tak, ale aj cez VPN
Používam vpn-slice na prechod cez VPN na adresy, ktoré začínajú 192.168.430. A poštový server má nielen symbolickú adresu, ktorá nie je subdoménou evilcorp, ale nemá ani IP adresu, ktorá začína 192.168.430. A samozrejme nedovolí nikomu zo všeobecnej siete, aby k nemu prišiel.
Aby Linux prešiel cez VPN a na poštový server, musíte ho pridať aj do vpn-slice. Povedzme, že adresa odosielateľa je 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 Skript na zvýšenie VPN s jedným argumentom
To všetko, samozrejme, nie je príliš pohodlné. Áno, môžete text uložiť do súboru a skopírovať a vložiť ho do konzoly namiesto toho, aby ste ho písali ručne, ale stále to nie je príliš príjemné. Na uľahčenie procesu môžete príkaz zabaliť do skriptu, ktorý sa bude nachádzať v PATH. Potom budete musieť zadať iba kód prijatý z aplikácie 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 Ak vložíte skript do connect~evilcorp~, môžete jednoducho písať do konzoly
connect_evil_corp 567987Teraz však musíte z nejakého dôvodu ponechať konzolu, v ktorej beží openconnect, otvorenú
Spustenie openconnect na pozadí
Našťastie sa autori openconnectu postarali a pridali do programu špeciálny kľúč -background, vďaka ktorému program po spustení funguje na pozadí. Ak to spustíte takto, môžete konzolu po spustení zavrieť
#!/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 Teraz nie je jasné, kam protokoly idú. Vo všeobecnosti protokoly naozaj nepotrebujeme, ale nikdy neviete. openconnect ich môže presmerovať na syslog, kde budú bezpečne uložené. do príkazu musíte pridať prepínač –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 A tak sa ukazuje, že openconnect funguje niekde na pozadí a nikoho neobťažuje, ale nie je jasné, ako to zastaviť. To znamená, že môžete samozrejme filtrovať výstup ps pomocou grep a hľadať proces, ktorého názov obsahuje openconnect, ale je to nejako zdĺhavé. Ďakujem autorom, ktorí mysleli aj na toto. Openconnect má kľúč -pid-file, pomocou ktorého môžete dať openconnect pokyn, aby zapísal svoj identifikátor procesu do súboru.
#!/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-pidTeraz môžete kedykoľvek zabiť proces pomocou príkazu
kill $(cat ~/vpn-pid)Ak neexistuje žiadny proces, kill bude preklínať, ale nevyhodí chybu. Ak tam súbor nie je, nič zlé sa tiež nestane, takže proces môžete pokojne zabiť v prvom riadku skriptu.
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-pidTeraz môžete zapnúť počítač, otvoriť konzolu a spustiť príkaz a odovzdať mu kód z aplikácie Google Authenticator. Potom je možné konzolu priklincovať.
Bez VPN-slice. Namiesto doslovu
Ukázalo sa, že je veľmi ťažké pochopiť, ako žiť bez VPN-slice. Musel som veľa čítať a googliť. Našťastie, po toľkých časoch strávených s problémom sa technické príručky a dokonca aj človek openconnect čítajú ako vzrušujúce romány.
V dôsledku toho som zistil, že vpn-slice, podobne ako natívny skript, upravuje smerovaciu tabuľku na samostatné siete.
Smerovacia tabuľka
Zjednodušene povedané, ide o tabuľku v prvom stĺpci, ktorá obsahuje, čím by mala začínať adresa, cez ktorú chce Linux prejsť, a v druhom stĺpci, ktorým sieťovým adaptérom na tejto adrese prejsť. V skutočnosti je reproduktorov viac, ale to nič nemení na podstate.
Ak chcete zobraziť smerovaciu tabuľku, musíte spustiť príkaz 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 Tu je každý riadok zodpovedný za to, kam musíte ísť, aby ste mohli poslať správu na nejakú adresu. Prvým je popis, kde má adresa začínať. Aby ste pochopili, ako určiť, že 192.168.0.0/16 znamená, že adresa by mala začínať 192.168, musíte si vygoogliť, čo je to maska IP adresy. Za dev je názov adaptéra, na ktorý sa má správa poslať.
Pre VPN vytvoril Linux virtuálny adaptér - tun0. Linka zabezpečuje, že cez ňu prechádza prevádzka pre všetky adresy začínajúce na 192.168
192.168.0.0/16 dev tun0 scope link Pomocou príkazu sa môžete pozrieť aj na aktuálny stav smerovacej tabuľky trasa -n (IP adresy sú šikovne anonymizované) Tento príkaz produkuje výsledky v inej forme a je všeobecne zavrhovaný, ale jeho výstup sa často nachádza v manuáloch na internete a musíte si ho vedieť prečítať.
Kde by mala IP adresa trasy začínať, je možné pochopiť z kombinácie stĺpcov Destination a Genmask. Tie časti IP adresy, ktoré zodpovedajú číslam 255 v Genmask, sa berú do úvahy, ale tie, kde je 0, nie sú. To znamená, že kombinácia Destination 192.168.0.0 a Genmask 255.255.255.0 znamená, že ak adresa začína na 192.168.0, potom požiadavka na ňu pôjde touto cestou. A ak cieľ 192.168.0.0, ale Genmask 255.255.0.0, požiadavky na adresy začínajúce na 192.168 pôjdu touto cestou
Aby som zistil, čo vpn-slice vlastne robí, rozhodol som sa pozrieť na stavy tabuliek pred a po
Pred zapnutím VPN to bolo takto
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 wlp3s0Po zavolaní openconnect bez vpn-slice to dopadlo takto
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 tun0A po zavolaní openconnect v kombinácii s vpn-slice takto
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 tun0Je vidieť, že ak nepoužívate vpn-slice, potom openconnect výslovne píše, že všetky adresy, okrem tých, ktoré sú špecificky uvedené, musia byť prístupné cez vpn.
Práve tu:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Tam je hneď vedľa neho naznačená ďalšia cesta, ktorú treba použiť, ak adresa, cez ktorú sa Linux snaží prejsť, nezodpovedá žiadnej maske z tabuľky.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Už tu je napísané, že v tomto prípade treba použiť štandardný Wi-Fi adaptér.
Verím, že cesta VPN sa používa, pretože je prvá v smerovacej tabuľke.
A teoreticky, ak odstránite túto predvolenú cestu zo smerovacej tabuľky, potom v spojení s dnsmasq openconnect by mala zabezpečiť normálnu prevádzku.
skúsil som
route del defaultA všetko fungovalo.
Smerovanie požiadaviek na poštový server bez vpn-slice
Ale mám aj mailový server s adresou 555.555.555.555, na ktorý je tiež potrebné pristupovať cez VPN. Trasu k nemu je tiež potrebné pridať ručne.
ip route add 555.555.555.555 via dev tun0A teraz je všetko v poriadku. Bez vpn-slice sa teda zaobídete, no musíte dobre vedieť, čo robíte. Teraz uvažujem o tom, že do posledného riadku natívneho openconnect skriptu pridám odstránenie predvolenej trasy a pridanie trasy pre mailer po pripojení k vpn, len aby bolo na mojom bicykli menej pohyblivých častí.
Pravdepodobne by tento doslov stačil na to, aby niekto pochopil, ako nastaviť VPN. Ale kým som sa snažil pochopiť, čo a ako mám robiť, prečítal som si pomerne veľa takých návodov, ktoré autorovi fungujú, no mne z nejakého dôvodu nefungujú, a rozhodol som sa sem pridať všetky kúsky, ktoré som našiel. Niečo také by ma veľmi potešilo.
Zdroj: hab.com