Chcete používat Linux v práci, ale firemní VPN to neumožňuje? Pak by vám tento článek mohl pomoci, i když to není jisté. Chci vás předem varovat, že rozumím problematice správy sítí špatně, takže je možné, že jsem to všechno udělal špatně. Na druhou stranu, je možné, že to dokážu napsat tak, že to bude srozumitelné běžným lidem, takže se doporučuji pokusit.
V článku je mnoho nadbytečných informací, ale bez těchto znalostí bych nemohl vyřešit problémy, které se mi nečekaně objevily při nastavování VPN. Myslím, že každý, kdo se pokusí aplikovat tento návod, narazí na problémy, které jsem neměl, a doufám, že tyto nadbytečné informace pomohou tyto problémy vyřešit samostatně.
Většinu příkazů uvedených v návodu je třeba provádět přes sudo, které bylo pro stručnost vynecháno. Mějte to na paměti.
Většina IP adres byla drasticky obfuskována, takže pokud uvidíte adresu jako 435.435.435.435 — měl by tam být nějaký normální IP, specifický pro vaši situaci.
Mám Ubuntu 18.04, ale myslím, že s malými úpravami lze návod aplikovat i na jiné distribuce. V tomto textu však Linux == Ubuntu.
Cisco Connect
Ti, kteří používají Windows nebo MacOS, se mohou připojit k naší firemní VPN prostřednictvím Cisco Connect, kterému je třeba zadat adresu brány a při každém připojení zadat heslo složené z pevné části a kódu generovaného Google Authenticator.
Pokud jde o Linux, nepodařilo se mi rozběhnout Cisco Connect, ale podařilo se mi najít doporučení používat openconnect, který byl vyvinut speciálně jako náhrada za Cisco Connect.
Openconnect
Teoreticky by v Ubuntu měl existovat speciální grafický rozhraní pro openconnect, ale mně se to nerozběhlo. Možná je to i k lepšímu.
V Ubuntu se openconnect instaluje z balíčkového manažera.
apt install openconnectIhned po instalaci můžete zkusit připojit k VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com je adresa fiktivní VPN
poxvuibr — jméno fiktivního uživatele
openconnect vás požádá o zadání hesla, které se skládá z pevné části a kódu z Google Authenticator, a poté se pokusí připojit k vpn. Pokud se to podařilo, gratuluji, můžete s klidem přeskočit bolestivé střední části a přejít k části o práci openconnect na pozadí. Pokud to nefunguje, můžete pokračovat. Ačkoli pokud se to podařilo připojit například z hostujícího Wi-Fi v práci, možná je brzy na radost, musíte zkusit zopakovat postup z domova.
Certifikát
S vysokou pravděpodobností nic nenaběhne a výstup openconnect bude vypadat nějak takto:
POST https://vpn.evilcorp.com/
Připojeno k 777.777.777.777:443
SSL vyjednávání s vpn.evilcorp.com
Ověření serverového certifikátu selhalo: podepisovatel nebyl nalezen
Certifikát z VPN serveru "vpn.evilcorp.com" selhal při ověření.
Důvod: podepisovatel nebyl nalezen
Aby bylo možné tomuto serveru důvěřovat v budoucnu, přidejte to možná do svého příkazového řádku:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Zadejte 'ano' pro přijetí, 'ne' pro zrušení; cokoliv jiného pro zobrazení: fgets (stdin): Operace právě probíháNa jedné straně je to nepříjemné, protože nedošlo k připojení k VPN, ale na druhé straně je jasné, jak tuto problémovou situaci řešit.
Server nám zde poslal certifikát, podle kterého lze určit, že se připojujeme skutečně k serveru naší společnosti, a ne k podvodníkovi, ale systému tento certifikát není znám. A proto nemůže zkontrolovat, zda je server pravý, nebo ne. A proto na chvíli přeruší činnost.
Aby se openconnect přeci jen připojil k serveru, je nutné mu jasně říci, jaký certifikát by měl od VPN serveru přijít pomocí klíče —servercert.
A zjistit, jaký certifikát nám server poslal, můžeme přímo z toho, co napsal openconnect. Z tohoto úryvku:
Aby bylo možné tomuto serveru důvěřovat v budoucnu, přidejte to možná do svého příkazového řádku:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Zadejte 'ano' pro přijetí, 'ne' pro zrušení; cokoliv jiného pro zobrazení: fgets (stdin): Operace právě probíháTímto příkazem se můžete zkusit připojit znovu
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMožná to teď funguje, pak můžete přejít na konec. Osobně mi Ubuntu ukázalo figu v tomto formátu.
POST https://vpn.evilcorp.com/
Připojeno k 777.777.777.777:443
SSL vyjednávání s vpn.evilcorp.com
Ověření certifikátu serveru selhalo: podepisovač nenalezen
Připojeno k HTTPS na vpn.evilcorp.com
XML POST povoleno
Zadejte prosím své uživatelské jméno a heslo.
POST https://vpn.evilcorp.com/
Obdržena odpověď CONNECT: HTTP/1.1 200 OK
CSTP připojeno. DPD 300, Keepalive 30
Nastavení DTLS selhalo; používá se SSL místo toho
Připojeno jako 192.168.333.222, používá se SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK odpovídá: Soubor již existuje
/etc/resolvconf/update.d/libc: Upozornění: /etc/resolv.conf není symbolický odkaz na /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 bude resolvovat, ale přístup na něj nebude možný. Adresy jako jira.evilcorp.com se vůbec neřeší.
Co se tu stalo, není mi jasné. Ale experiment ukazuje, že pokud do /etc/resolv.conf přidáte řádek
nameserver 192.168.430.534adresy uvnitř VPN se začnou kouzelně resolvovat a pak se k nim budete moci dostat, tedy to, co hledá, jaké DNS řešit adresy, hledá přesně v /etc/resolv.conf, a ne někam jinam.
To, že připojení k VPN existuje a funguje, lze ověřit i bez změn v /etc/resolv.conf, stačí zadat do prohlížeče nikoli symbolické jméno zdroje z VPN, ale jeho IP adresu.
Nakonec se ukazuje, že existují dva problémy
- při připojení k VPN se její DNS nepodchytí
- veškerý provoz prochází přes VPN, která neumožňuje přístup na internet
Co dělat, teď řeknu, ale nejprve trochu automatizace.
Automatické zadávání pevné části hesla
Do současného okamžiku jste pravděpodobně již zadali heslo alespoň pětkrát a tento proces vás už dost unavil. Za prvé, protože je heslo dlouhé, a za druhé, protože je třeba se vejít do pevného časového intervalu.
Konečné řešení problému nebylo do článku zahrnuto, ale můžete udělat tak, aby se pevná část hesla nemusela zadávat tolikrát.
Předpokládejme, že pevná část hesla je fixedPassword, a část z Google Authenticator 567 987. Celé heslo openconnect lze předat prostřednictvím standardního vstupu pomocí argumentu --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNyní se můžete neustále vracet k poslední zadané příkazu a měnit jen část z Google Authenticator.
Podnikového VPN neumožňuje přístup na internet.
Opravdu to není příliš pohodlné, když pro přístup na habr musíte používat jiný počítač. Nedostatek možnosti kopírovat a vkládat ze stackoverflow může opravdu paralyzovat práci, a proto je potřeba něco udělat.
Je třeba nějak zařídit, aby se při přístupu k prostředku z vnitřní sítě Linux připojoval na VPN a při přístupu na Habr surfoval po internetu.
Openconnect po spuštění a instalaci připojení k VPN vykonává speciální skript, který se nachází v /usr/share/vpnc-scripts/vpnc-script. Do skriptu jsou předávány nějaké proměnné a ten provádí nastavení VPN. Bohužel jsem se nedokázal dostat k rozdělení toků provozu mezi firemní VPN a zbylým internetem pomocí standardního skriptu.
Zřejmě speciálně pro nás byla vyvinuta utilita vpn-slice, která umožňuje směrovat provoz po dvou kanálech bez zbytečných komplikací. No, tedy tancovat bude třeba, ale šamanem být rozhodně nemusíte.
Rozdělení provozu pomocí vpn-slice
Za prvé, vpn-slice bude třeba nainstalovat, s tím si budete muset poradit sami. Pokud budou v komentářích dotazy, napíšu k tomu samostatný příspěvek. Ale je to běžný program napsaný v Pythonu, takže by neměly být žádné komplikace. Instaloval jsem to pomocí virtualenv.
A dál je třeba utilitu použít, pomocí klíče --script uvést openconnect, aby místo standardního skriptu použil 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 Do --script se předává řetězec s příkazem, který se má zavolat místo skriptu. .\/bin\/vpn-slice — cesta k spustitelnému souboru vpn-slice, 192.168.430.0\/24 — maska adresů, pro které se má chodit na VPN. Mám na mysli, že pokud adresa začíná na 192.168.430 — tak zdroj s touto adresou je třeba hledat uvnitř VPN.
Nyní by situace měla být téměř normální. Téměř. Nyní je možné vstoupit na Habr a lze se připojit k vnitrofiremnímu zdroji podle IP, ale není možné se připojit k vnitrofiremnímu zdroji podle symbolického jména. Pokud se do hosts zapíše odpovídající přiřazení symbolického jména a adresy — mělo by to fungovat. A fungovat, dokud se IP nezmění. Linux nyní umí chodit na internet nebo do vnitrofiremní sítě podle IP. Ale pro určení adresy se stále používá nefiremní DNS.
Problém může také nastat v tom smyslu, že v práci je vše v pořádku, ale doma se do firemních zdrojů můžete dostat pouze přes IP. To proto, že když jste připojeni k firemnímu Wi-Fi, používá se také firemní DNS, ve kterém se symbolické adresy z VPN rozřeší, i když procházet na takovou adresu bez použití VPN stále nelze.
Automatická úprava souboru hosts
Pokud požádáte vpn-slice zdvořile, může po vytvoření VPN navštívit její DNS, najít tam IP adresy potřebných zdrojů podle jejich symbolických názvů a zapsat je do hosts. Po vypnutí VPN budou tyto adresy z hosts odstraněny. K tomu je třeba předat symbolické názvy do vpn-slice jako argumenty. Takto.
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 Teď by to mělo fungovat jak v kanceláři, tak na pláži.
Hledat adresy všech subdomén v DNS, které poskytla VPN
Pokud je v síti jen několik adres, pak je přístup s automatickou úpravou souboru hosts zcela funkční. Ale pokud je ve síti mnoho zdrojů, budete je muset neustále přidávat do skriptu, jako například zoidberg.test.evilcorp.com; zoidberg je takový jeden z testovacích stánků.
Ale nyní, když už trochu rozumíme, jak to funguje, můžeme tuto potřebu odstranit.
Pokud po aktivaci VPN podíváte do \/etc\/hosts, uvidíte takový řádek
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Ano, a do resolv.conf byla přidána nová řádka. Zkrátka, vpn-slice nějakým způsobem určila, kde se nachází DNS server pro VPN.
Nyní je třeba udělat něco takového, aby pro zjištění IP adresy doménového jména končícího na evilcorp.com Linux chodil do firemního DNS, a pokud potřebuje něco jiného, pak do defaultního.
Docela dlouho jsem googlil a zjistil, že taková funkčnost je v Ubuntu hned po instalaci. Mám na mysli možnost používat pro rozlišení názvů místní DNS server dnsmasq.
To znamená, že můžete nastavit, aby Linux vždy pro IP adresy chodil k místnímu DNS serveru, který následně, podle doménového názvu, bude hledat IP na odpovídajícím externím DNS serveru.
Pro správu všeho, co souvisí se sítěmi a síťovými připojeními, se v Ubuntu používá NetworkManager a grafické rozhraní pro výběr, například Wi-Fi připojení, je pouze frontend k němu.
Budeme muset prozkoumat jeho konfiguraci.
- Vytvořit soubor v /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Všimněte si tečky před evilcorp. Signalizuje dnsmasq, že všechny subdomény evilcorp.com by měly být hledány právě v korporátním DNS.
- Říct NetworkManager, že pro řešení jmen je třeba použít dnsmasq
Konfigurace network-manager se nachází v /etc/NetworkManager/NetworkManager.conf. Je třeba tam přidat:
[main]
dns=dnsmasq
- Restartovat NetworkManager
service network-manager restartNyní, po připojení k VPN pomocí balíčku openconnect a vpn-slice, bude IP správně určena, i když nebudu přidávat symbolické adresy do argumentů k vpnslice.
Jak se připojit přes VPN k jednotlivým službám
Po úspěšném připojení k VPN jsem se radoval asi dva dny, ale pak jsem zjistil, že pokud se připojuji k VPN ne z kancelářské sítě, nefunguje mi pošta. Příznak je povědomý, že?
Pošta se nachází na mail.publicevilcorp.com, což znamená, že nespadá pod pravidlo v dnsmasq a adresa poštovního serveru se hledá přes veřejný DNS.
V kanceláři se přece používá DNS, ve kterém je tato adresa. Tedy jsem si to myslel. Po přidání řádku do dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
se situace nijak nezměnila. IP zůstala stejná. Musel jsem chodit do práce.
A až později, když jsem se ponořil do situace a trochu si problém osvětlil, mi jeden chytrý člověk poradil, jak ho vyřešit. Potřeboval jsem se připojit k poštovnímu serveru ne jen tak, ale přes VPN.
Používám vpn-slice, abych šel přes VPN na adresy, které začínají na 192.168.430. A poštovní server nejen, že jeho symbolická adresa není subdoména evilcorp, ale jeho IP adresa také nezačíná na 192.168.430. A z veřejné sítě nikoho k sobě samozřejmě nepouští.
Aby Linux mohl chodit přes VPN k poštovnímu serveru, je potřeba přidat ho do vpn-slice. Řekněme, že adresa poštovníka 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 pro spuštění VPN s jedním argumentem
Všechno to samozřejmě není příliš pohodlné. Ano, můžeme si text uložit do souboru a zkopírovat ho do konzole, místo abychom ho psali ručně, ale i tak to není nic příjemného. Pro usnadnění procesu bychom mohli zabalení příkazu do skriptu, který bude v PATH. A pak stačí pouze zadat kód, který získáme z 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 Pokud umístíme skript do connect~evilcorp~, budeme moci jednoduše psát v konzoli.
connect_evil_corp 567987Ale nyní budeme muset stejně nějakou dobu držet konzoli, ve které je spuštěn openconnect, otevřenou.
Spuštění openconnect na pozadí.
Naštěstí se autoři openconnect postarali o nás a do programu přidali speciální klíč —background, který způsobí, že program po spuštění běží na pozadí. Pokud ji spustíme tímto způsobem, můžeme po spuštění zavřít konzoli.
#!/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 Teď je jen otázka, kam odcházejí logy. Logy nám vlastně nejsou moc potřebné, ale kdo ví. Openconnect může přesměrovat logy do syslogu, kde budou uchovány v celistvosti. Je potřeba to přidat do příkazu s klíčem —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 se ukazuje, že openconnect běží někde na pozadí a nikomu nepřekáží, ale jak ho zastavit, to je otázka. Samozřejmě, můžeme filtrovat výstup ps grepem a hledat proces, jehož název obsahuje openconnect, ale to je dost pracné. Děkujeme autorům, kteří na to také mysleli. V openconnect existuje klíč —pid-file, pomocí kterého můžeme instruovat openconnect, aby zapisoval identifikátor svého procesu do souboru.
#!/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-pidNyní je vždy možné proces zastavit příkazem.
kill $(cat ~/vpn-pid)Pokud proces neexistuje, kill se ozve, ale chybu nehodí. Pokud soubor neexistuje, také se nic hrozného nestane, takže můžeme klidně zabít proces v prvním řádku 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-pidNyní můžeme zapnout počítač, otevřít konzoli a spustit příkaz s kódem z Google Authenticator. Konzoli pak můžeme zastavit.
Bez vpn-slice. Místo závěrečného slova.
Porozumět, jak žít bez vpn-slice, se ukázalo být velmi obtížné. Musel jsem hodně číst a googlit. Naštěstí, když jsem strávil tolik času s problémem, technické manuály a dokonce i man openconnect se čtou jako vzrušující romány.
Nakonec jsem zjistil, že vpn-slice, stejně jako původní skript, mění tabulku směrování pro oddělení sítí.
Tabulka směrování
Je to, zjednodušeně řečeno, tabulka, jejíž první sloupec obsahuje, od čeho by měla začínat adresa, kterou se Linux snaží dosáhnout, a ve druhém sloupci, přes který síťový adaptér by měla tato adresa projít. Ve skutečnosti je sloupců více, ale podstata se tím nemění.
Chcete-li zobrazit tabulku směrování, je třeba zadat příkaz ip route
default via 192.168.1.1 dev wlp3s0 proto dhcp metrika 600
192.168.430.0/24 dev tun0 rozsah link
192.168.1.0/24 dev wlp3s0 proto kernel rozsah link src 192.168.1.534 metrika 600
192.168.430.534 dev tun0 rozsah link Každý řádek zde odpovídá tomu, kam je třeba jít, aby se odeslala zpráva na určitou adresu. Prvním prvkem je popis, od čeho by měla adresa začínat. Chcete-li pochopit, jak určit, že 192.168.0.0/16 znamená, že adresa musí začínat na 192.168, je třeba vyhledat, co je to maska IP adresy. Za dev následuje název adaptéru, na který je třeba odeslat zprávu.
Pro VPN Linux vytvořil virtuální adaptér — tun0. Za to, že veškerý provoz pro všechny adresy začínající na 192.168 jde přes něj, odpovídá řádek
192.168.0.0/16 dev tun0 rozsah link Další aktuální stav tabulky směrování lze zkontrolovat pomocí příkazu route -n (IP adresy jsou umně anonymizovány) Tento příkaz vrací výsledky v jiném formátu a obecně je zastaralý, ale jeho výstup se často objevuje v návodech na internetu a je důležité ho umět číst.
Od čeho by měla začínat IP adresa pro trasu, lze pochopit z kombinace sloupců Destination a Genmask. Ty části IP adresy, kterým v Genmask odpovídají čísla 255, se zohledňují, zatímco ty, kde je 0 — ne. To znamená, že kombinace Destination 192.168.0.0 a Genmask 255.255.255.0 znamená, že pokud adresa začíná na 192.168.0, pak požadavek na ni půjde po této trase. A pokud Destination 192.168.0.0, ale Genmask 255.255.0.0, pak po této trase půjdou požadavky na adresy, které začínají na 192.168.
Abych zjistil, co vlastně vpn-slice dělá, rozhodl jsem se podívat na stavy tabulek před a po
Před zapnutím VPN to vypadalo takto
route -n
Jádrová IP směrovací tabulka
Cíl Gateway Genmask Flags Metoda Ref Použití Rozhraní
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 zavolání openconnect bez vpn-slice to vypadalo takto
route -n
Tabulka směrování jádra IP
Cíl Brána Genmask Flagg Metric Ref Použít Interface
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 volání openconnect v kombinaci s vpn-slice to vypadá takto
Tabulka směrování jádra IP
Cíl Brána Genmask Flagg Metric Ref Použít Interface
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 vidět, že pokud nepoužíváte vpn-slice, openconnect výslovně píše, že pro všechny adresy kromě zvlášť uvedených se musí používat vpn.
Tady:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Hned vedle je uvedena další cesta, kterou je třeba použít, pokud adresa, kterou se Linux pokouší použít, neodpovídá žádné masce z tabulky.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Zde už je napsáno, že v takovém případě se musí používat standardní wifi adaptér.
Myslím, že cesta pro VPN se používá, protože je první v tabulce směrování.
A teoreticky, pokud odstraníte tuto výchozí cestu z tabulky směrování, openconnect by měl zajišťovat normální funkci ve spojení s dnsmasq.
Zkusil jsem
route del defaultA všechno začalo fungovat.
Smerování dotazů na poštovní server bez vpn-slice
Ale mám ještě poštovní server s adresou 555.555.555.555, na který se musí rovněž jít přes vpn. Také je třeba ručně přidat cestu k němu.
ip route add 555.555.555.555 via dev tun0A teď už všechno funguje správně. Takže se obejít bez vpn-slice skutečně dá, ale už je třeba mít dobré znalosti o tom, co děláte. Teď přemýšlím, zda do posledního řádku původního skriptu openconnect nepřidat odstranění výchozí cesty a přidání cesty pro poštu po připojení k vpn, prostě abych snížil počet pohyblivých částí ve svém kole.
Možná by někomu na pochopení toho, jak nastavit VPN, stačilo toto poselství. Ale já, zatímco jsem se snažil pochopit, co a jak mám dělat, jsem přečetl spoustu takových příruček, které fungují autorovi, ale z nějakého důvodu nefungují mně, a rozhodl jsem se sem přidat všechny úryvky, které jsem našel. O něco takového bych se velmi potěšil.
Zdroj: habr.com
