Chcete v práci používat Linux, ale vaše firemní VPN vám to nedovolí? Pak může pomoci tento článek, i když to není jisté. Předem upozorňuji, že problematice správy sítě dobře nerozumím, takže je možné, že jsem vše udělal špatně. Na druhou stranu je možné, že dokážu napsat návod tak, že bude srozumitelný i běžnému člověku, proto radím, zkuste to.
Článek obsahuje spoustu zbytečných informací, ale bez těchto znalostí bych nedokázal vyřešit problémy, které se mi nečekaně objevily s nastavením VPN. Myslím, že každý, kdo se pokusí použít tuto příručku, bude mít problémy, které jsem neměl já, a doufám, že tyto dodatečné informace pomohou tyto problémy vyřešit samostatně.
Většinu příkazů použitých v této příručce je třeba spouštět přes sudo, které bylo kvůli stručnosti odstraněno. Mějte na paměti.
Většina IP adres byla silně zamlžena, takže pokud vidíte adresu jako 435.435.435.435, musí tam být nějaká normální IP, specifická pro váš případ.
Mám Ubuntu 18.04, ale myslím, že s drobnými změnami lze průvodce použít i na jiné distribuce. Nicméně v tomto textu Linux == Ubuntu.
Cisco Connect
Uživatelé se systémem Windows nebo MacOS se mohou k naší firemní VPN připojit přes Cisco Connect, který musí zadat adresu brány a při každém připojení zadat heslo skládající se z pevné části a kódu vygenerovaného aplikací Google Authenticator.
V případě Linuxu se mi nepodařilo zprovoznit Cisco Connect, ale podařilo se mi vygooglovat doporučení použít openconnect, vytvořené speciálně jako náhrada Cisco Connect.
Openconnect
Teoreticky má Ubuntu speciální grafické rozhraní pro openconnect, ale nefungovalo mi to. Možná je to k lepšímu.
Na Ubuntu se openconnect instaluje ze správce balíčků.
apt install openconnectIhned po instalaci se můžete zkusit připojit k VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com je adresa fiktivní VPN
poxvuibr - fiktivní uživatelské jméno
openconnect vás požádá o zadání hesla, které se, připomenu, skládá z pevné části a kódu z Google Authenticator, a poté se pokusí připojit k vpn. Pokud to funguje, gratuluji, můžete klidně přeskočit střed, což je velká bolest, a přejít k bodu o openconnect běžícím na pozadí. Pokud to nebude fungovat, můžete pokračovat. I když pokud to fungovalo při připojení například z hostující Wi-Fi v práci, pak je možná příliš brzy na jásání, měli byste zkusit postup zopakovat z domova.
Certifikát
Je vysoká pravděpodobnost, že se nic nespustí a výstup openconnect bude vypadat nějak 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 jednu stranu je to nepříjemné, protože nebylo připojení k VPN, ale na druhou stranu, jak tento problém opravit, je v zásadě jasné.
Zde nám server poslal certifikát, podle kterého můžeme určit, že je navázáno spojení se serverem naší rodné korporace, nikoli se zlým podvodníkem, a tento certifikát je systému neznámý. A proto nemůže zkontrolovat, zda je server skutečný nebo ne. A tak to pro každý případ přestane fungovat.
Aby se openconnect mohl připojit k serveru, musíte mu explicitně sdělit, který certifikát má pocházet ze serveru VPN pomocí klíče —servercert
A jaký certifikát nám server poslal, můžete zjistit přímo z toho, co openconnect vytiskl. Tady je z tohoto dílu:
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 progressPomocí tohoto příkazu se můžete pokusit znovu připojit
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMožná to teď funguje, pak můžete přejít na konec. Osobně mi ale Ubunta ukázala fík v této podobě
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 vyřeší, ale nebudete tam moci jít. Adresy jako jira.evilcorp.com se vůbec neřeší.
Co se tu stalo, mi není jasné. Ale experiment ukazuje, že pokud přidáte řádek do /etc/resolv.conf
nameserver 192.168.430.534pak se adresy uvnitř VPN začnou magicky rozlišovat a můžete jimi procházet, to znamená, že to, co DNS hledá pro řešení adres, vypadá konkrétně v /etc/resolv.conf a ne někde jinde.
Můžete ověřit, že existuje připojení k VPN a že funguje, aniž byste provedli jakékoli změny v /etc/resolv.conf; k tomu stačí do prohlížeče zadat nikoli symbolický název zdroje z VPN, ale jeho IP adresu
V důsledku toho existují dva problémy
- Při připojování k VPN se její dns nezvedne
- veškerý provoz jde přes VPN, která neumožňuje přístup k internetu
Řeknu vám, co dělat teď, ale nejdřív trochu automatizace.
Automatické zadání pevné části hesla
Touto dobou jste s největší pravděpodobností již zadali své heslo nejméně pětkrát a tento postup vás již unavuje. Jednak proto, že heslo je dlouhé, a jednak proto, že se při zadávání musíte vejít do pevně stanoveného časového období
Konečné řešení problému nebylo součástí článku, ale můžete se ujistit, že pevná část hesla se nemusí zadávat mnohokrát.
Řekněme, že pevná část hesla je fixedPassword a část z Google Authenticator je 567 987. Celé heslo lze předat openconnect přes standardní vstup 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ímu zadanému příkazu a měnit tam pouze část Google Authenticator.
Firemní VPN vám neumožňuje surfovat po internetu.
Obecně není příliš nepohodlné, když musíte k návštěvě Habr použít samostatný počítač. Neschopnost zkopírovat a vložit ze stackoverfow může obecně paralyzovat práci, takže je třeba něco udělat.
Musíme to nějak zorganizovat tak, že když potřebujete přistupovat k prostředku z vnitřní sítě, Linux šel do VPN a když potřebujete jít do Habr, šel na internet.
openconnect po spuštění a navázání spojení s vpn spustí speciální skript, který se nachází v /usr/share/vpnc-scripts/vpnc-script. Některé proměnné jsou předány skriptu jako vstup a konfiguruje VPN. Bohužel jsem nemohl přijít na to, jak rozdělit toky provozu mezi firemní VPN a zbytek internetu pomocí nativního skriptu.
Nástroj vpn-slice byl zjevně vyvinut speciálně pro lidi, jako jsem já, což vám umožňuje posílat provoz přes dva kanály, aniž byste tančili s tamburínou. No, to znamená, že budete muset tančit, ale nemusíte být šaman.
Oddělení provozu pomocí vpn-slice
Nejprve budete muset nainstalovat vpn-slice, na to budete muset přijít sami. Pokud budou v komentářích dotazy, napíšu o tom samostatný příspěvek. Ale toto je běžný program Python, takže by neměly být žádné potíže. Nainstaloval jsem pomocí virtualenv.
A poté je třeba použít obslužný program pomocí přepínače -script, což znamená, že pro openconnect musíte místo standardního skriptu použít 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 je předán řetězec s příkazem, který je třeba volat místo skriptu. ./bin/vpn-slice - cesta ke spustitelnému souboru vpn-slice 192.168.430.0/24 - maska adres, na které se má přejít ve vpn. Zde máme na mysli, že pokud adresa začíná 192.168.430, pak je třeba zdroj s touto adresou hledat uvnitř VPN
Situace by nyní měla být téměř normální. Téměř. Nyní můžete přejít na Habr a můžete přejít na vnitropodnikový zdroj pomocí ip, ale nemůžete přejít na vnitropodnikový zdroj pomocí symbolického jména. Pokud zadáte shodu mezi symbolickým jménem a adresou v hostitelích, vše by mělo fungovat. A pracuj, dokud se IP nezmění. Linux nyní může přistupovat k Internetu nebo intranetu v závislosti na IP. K určení adresy se ale stále používá nefiremní DNS.
Problém se může projevit i v této podobě – v práci je vše v pořádku, ale doma se k interním firemním zdrojům dostanete pouze přes IP. Když jste totiž připojeni k firemní Wi-Fi, využívá se i firemní DNS a v něm se řeší symbolické adresy z VPN, přesto, že bez použití VPN se na takovou adresu stále nedá jít.
Automatická úprava souboru hosts
Pokud je vpn-slice požádán zdvořile, může po zvýšení VPN přejít na svůj DNS, najít tam IP adresy potřebných zdrojů podle jejich symbolických jmen a zadat je do hostitelů. Po vypnutí VPN budou tyto adresy odstraněny z hostitelů. Chcete-li to provést, musíte vpn-slice předat symbolické názvy jako argumenty. Takhle.
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 Nyní by vše mělo fungovat jak v kanceláři, tak na pláži.
Vyhledejte adresy všech subdomén v DNS dané VPN
Pokud je v síti málo adres, pak přístup automatické úpravy souboru hosts funguje docela dobře. Ale pokud je na síti hodně zdrojů, pak budete muset neustále přidávat řádky jako zoidberg.test.evilcorp.com do skriptu zoidberg je název jedné z testovacích stolic.
Ale teď, když trochu rozumíme, proč lze tuto potřebu eliminovat.
Pokud se po zvýšení VPN podíváte do /etc/hosts, můžete vidět tento řádek
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
A do resolv.conf byl přidán nový řádek. Stručně řečeno, vpn-slice nějak určilo, kde se nachází server DNS pro vpn.
Nyní se musíme ujistit, že abychom zjistili IP adresu názvu domény končící na evilcorp.com, Linux přejde na firemní DNS, a pokud je potřeba něco jiného, pak na výchozí.
Poměrně dlouho jsem hledal na Googlu a zjistil jsem, že taková funkce je v Ubuntu k dispozici ihned po vybalení. To znamená možnost použít k překladu názvů místní server DNS dnsmasq.
To znamená, že se můžete ujistit, že Linux vždy najde adresy IP na místní server DNS, který pak v závislosti na názvu domény vyhledá IP na odpovídajícím externím serveru DNS.
Pro správu všeho, co souvisí se sítěmi a síťovými připojeními, používá Ubuntu NetworkManager a grafické rozhraní pro výběr například Wi-Fi připojení je k němu jen frontendem.
Budeme muset vylézt v jeho konfiguraci.
- Vytvořte soubor v /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Věnujte pozornost bodu před evilcorp. Signalizuje dnsmasq, že všechny subdomény evilcorp.com by měly být prohledány v podnikovém DNS.
- Řekněte NetworkManager, aby používal dnsmasq pro překlad názvů
Konfigurace správce sítě se nachází v /etc/NetworkManager/NetworkManager.conf Musíte tam přidat:
[hlavní] dns=dnsmasq
- Restartujte NetworkManager
service network-manager restartNyní, po připojení k VPN pomocí openconnect a vpn-slice, bude ip určena normálně, i když k argumentům vpnslice nepřidáte symbolické adresy.
Jak přistupovat k jednotlivým službám přes VPN
Poté, co se mi podařilo připojit k VPN, jsem byl dva dny velmi rád a pak se ukázalo, že když se připojím k VPN z mimo kancelářskou síť, tak pošta nefunguje. Symptom je známý, že?
Naše pošta je umístěna na mail.publicevilcorp.com, což znamená, že nespadá pod pravidlo dnsmasq a adresa poštovního serveru se hledá prostřednictvím veřejného DNS.
Kancelář stále používá DNS, který obsahuje tuto adresu. To je to co jsem myslel. Ve skutečnosti po přidání řádku do dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
situace se vůbec nezměnila. ip zůstala stejná. Musel jsem jít do práce.
A až později, když jsem se do situace ponořil hlouběji a problém trochu pochopil, mi jeden chytrý člověk řekl, jak to vyřešit. K poštovnímu serveru bylo nutné se připojit nejen tak, ale přes VPN
Používám vpn-slice k procházení VPN na adresy, které začínají 192.168.430. A poštovní server má nejen symbolickou adresu, která není subdoménou evilcorp, ale také nemá IP adresu začínající 192.168.430. A samozřejmě nedovolí nikomu z obecné sítě, aby k němu přišel.
Aby Linux prošel VPN a na poštovní server, musíte jej přidat také do vpn-slice. Řekněme, že adresa odesílatele 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 zvýšení VPN s jedním argumentem
To vše samozřejmě není příliš pohodlné. Ano, můžete text uložit do souboru a zkopírovat a vložit do konzoly místo ručního psaní, ale stále to není příliš příjemné. Pro usnadnění procesu můžete příkaz zabalit do skriptu, který bude umístěn v PATH. Poté budete muset zadat pouze kód přijatý z aplikace 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 vložíte skript do connect~evilcorp~, můžete jednoduše zapisovat do konzole
connect_evil_corp 567987Nyní ale stále musíte z nějakého důvodu ponechat konzoli, ve které běží openconnect, otevřenou
Spuštění openconnect na pozadí
Naštěstí si na nás dali autoři openconnectu a do programu přidali speciální klíč -background, díky kterému program po spuštění funguje na pozadí. Pokud to takto spustíte, můžete konzoli po spuštění zavřít
#!/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 Nyní není jasné, kam záznamy jdou. Obecně platí, že protokoly opravdu nepotřebujeme, ale nikdy nevíte. openconnect je může přesměrovat na syslog, kde budou uchovávány v bezpečí. musíte k příkazu přidat přepí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 se ukazuje, že openconnect funguje někde na pozadí a nikoho neobtěžuje, ale není jasné, jak to zastavit. To znamená, že můžete samozřejmě filtrovat výstup ps pomocí grep a hledat proces, jehož název obsahuje openconnect, ale to je nějak zdlouhavé. Děkuji autorům, kteří o tom také přemýšleli. Openconnect má klíč -pid-file, pomocí kterého můžete dát openconnect pokyn, aby zapsal svůj identifikátor 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í můžete vždy zabít proces pomocí příkazu
kill $(cat ~/vpn-pid)Pokud neexistuje žádný proces, kill bude proklínat, ale nevyhodí chybu. Pokud tam soubor není, nic špatného se také nestane, takže můžete 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ůžete zapnout počítač, otevřít konzolu a spustit příkaz a předat mu kód z Google Authenticator. Poté lze konzolu přibít.
Bez VPN-slice. Místo doslovu
Ukázalo se, že je velmi obtížné pochopit, jak žít bez VPN-slice. Musel jsem hodně číst a googlit. Naštěstí, po tolika času stráveném nad problémem, se technické příručky a dokonce i man openconnect čtou jako vzrušující romány.
V důsledku toho jsem zjistil, že vpn-slice, stejně jako nativní skript, upravuje směrovací tabulku na samostatné sítě.
Směrovací tabulka
Zjednodušeně řečeno jde o tabulku v prvním sloupci, která obsahuje, čím má začínat adresa, kterou chce Linux procházet, a ve druhém sloupci, který síťový adaptér má na této adrese procházet. Ve skutečnosti je reproduktorů více, ale to nic nemění na podstatě.
Chcete-li zobrazit směrovací tabulku, musíte spustit pří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 Zde je každý řádek zodpovědný za to, kam musíte jít, abyste mohli poslat zprávu na nějakou adresu. První je popis, kde má adresa začínat. Abyste pochopili, jak zjistit, že 192.168.0.0/16 znamená, že adresa by měla začínat 192.168, musíte si vygooglovat, co je to maska IP adresy. Za dev je název adaptéru, na který má být zpráva odeslána.
Pro VPN vytvořil Linux virtuální adaptér - tun0. Linka zajišťuje, že přes ni projde provoz pro všechny adresy začínající na 192.168
192.168.0.0/16 dev tun0 scope link Pomocí příkazu se také můžete podívat na aktuální stav směrovací tabulky trasa -n (IP adresy jsou chytře anonymizovány) Tento příkaz vytváří výsledky v jiné podobě a je obecně zastaralý, ale jeho výstup často najdete v příručkách na internetu a musíte jej umět číst.
Kde by měla IP adresa trasy začínat, lze pochopit z kombinace sloupců Destination a Genmask. Ty části IP adresy, které odpovídají číslům 255 v Genmask, jsou brány v úvahu, ale ty, kde je 0, nejsou. To znamená, že kombinace Destination 192.168.0.0 a Genmask 255.255.255.0 znamená, že pokud adresa začíná 192.168.0, pak požadavek na ni půjde touto cestou. A pokud Cíl 192.168.0.0, ale Genmask 255.255.0.0, pak požadavky na adresy začínající na 192.168 půjdou touto cestou
Abych zjistil, co vpn-slice vlastně dělá, rozhodl jsem se podívat na stavy tabulek před a po
Před zapnutím VPN to bylo 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 zavolání 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 zavolání openconnect v kombinaci 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 vidět, že pokud nepoužíváte vpn-slice, pak openconnect výslovně píše, že všechny adresy, kromě těch, které jsou konkrétně uvedeny, musí být přístupné přes vpn.
Zde:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Tam je hned vedle něj naznačena další cesta, kterou je nutné použít, pokud adresa, kterou se Linux snaží projít, neodpovídá žádné masce z tabulky.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Již zde je napsáno, že v tomto případě je potřeba použít standardní Wi-Fi adaptér.
Věřím, že cesta VPN je použita, protože je první ve směrovací tabulce.
A teoreticky, pokud odstraníte tuto výchozí cestu ze směrovací tabulky, pak ve spojení s dnsmasq openconnect by měl zajistit normální provoz.
zkusil jsem
route del defaultA vše fungovalo.
Směrování požadavků na poštovní server bez vpn-slice
Mám ale také poštovní server s adresou 555.555.555.555, na který je také potřeba přistupovat přes VPN. Trasu k němu je také potřeba přidat ručně.
ip route add 555.555.555.555 via dev tun0A teď je vše v pořádku. Bez vpn-slice se tedy obejdete, ale musíte dobře vědět, co děláte. Nyní přemýšlím o přidání do posledního řádku nativního openconnect skriptu odstranění výchozí trasy a přidání trasy pro mailer po připojení k vpn, jen aby bylo na mém kole méně pohyblivých částí.
Pravděpodobně by tento doslov stačil, aby někdo pochopil, jak nastavit VPN. Ale když jsem se snažil pochopit, co a jak mám dělat, přečetl jsem docela dost takových návodů, které autorovi fungují, ale mně z nějakého důvodu nefungují, a rozhodl jsem se sem přidat všechny kousky, které jsem našel. Za něco takového bych měl velkou radost.
Zdroj: www.habr.com