Szeretné használni a Linuxot a munkahelyén, de a vállalati VPN nem engedi? Akkor ez a cikk segíthet, bár ez nem biztos. Szeretném előre figyelmeztetni, hogy nem értek jól a hálózati adminisztrációs kérdésekhez, így lehetséges, hogy mindent rosszul csináltam. Másrészt lehetséges, hogy úgy tudok útmutatót írni, hogy az hétköznapi emberek számára is érthető legyen, ezért azt tanácsolom, próbálja ki.
A cikk sok felesleges információt tartalmaz, de ezen ismeretek nélkül nem tudtam volna megoldani a VPN beállításával váratlanul felmerülő problémákat. Úgy gondolom, hogy bárki, aki megpróbálja használni ezt az útmutatót, olyan problémákkal fog szembesülni, amelyek nálam nem voltak, és remélem, hogy ez a kiegészítő információ önmagában segít megoldani ezeket a problémákat.
Az ebben az útmutatóban használt parancsok többségét a sudo-n keresztül kell futtatni, amelyet a rövidség kedvéért eltávolítottunk. Tartsd észben.
A legtöbb IP-címet erősen homályosították, ezért ha olyan címet lát, mint a 435.435.435.435, akkor ott kell lennie valamilyen normál IP-címnek, az Ön esetére jellemző.
Ubuntu 18.04-em van, de szerintem kisebb változtatásokkal az útmutató más disztribúciókra is alkalmazható. Ebben a szövegben azonban Linux == Ubuntu.
Cisco Connect
A Windows vagy MacOS operációs rendszert használók a Cisco Connect segítségével csatlakozhatnak vállalati VPN-ünkhöz, amelynek meg kell adnia az átjáró címét, és minden csatlakozáskor meg kell adnia egy jelszót, amely egy rögzített részből és a Google Authenticator által generált kódból áll.
Linux esetén a Cisco Connect-et nem tudtam futtatni, de sikerült a Google-ban egy ajánlást találnom az openconnect használatára, amely kifejezetten a Cisco Connect leváltására készült.
Nyissa meg a kapcsolatot
Elméletileg az Ubuntunak van egy speciális grafikus felülete az openconnecthez, de nekem nem működött. Talán jobb lesz.
Ubuntu esetén az openconnect a csomagkezelőből van telepítve.
apt install openconnectKözvetlenül a telepítés után megpróbálhat csatlakozni egy VPN-hez
openconnect --user poxvuibr vpn.evilcorp.comA vpn.evilcorp.com egy fiktív VPN címe
poxvuibr - fiktív felhasználónév
Az openconnect egy jelszó megadását kéri, ami, hadd emlékeztessem, egy fix részből és a Google Authenticator kódjából áll, majd megpróbál csatlakozni a vpn-hez. Ha működik, gratulálok, nyugodtan kihagyhatod a közepét, ami nagyon fájdalmas, és továbbléphetsz arra a pontra, hogy a háttérben fut az openconnect. Ha nem megy, akkor folytathatja. Bár ha működött, amikor például egy munkahelyi vendég Wi-Fi-ről csatlakozik, akkor lehet, hogy túl korai örülni, meg kell próbálnia otthonról megismételni az eljárást.
bizonyítvány
Nagy a valószínűsége annak, hogy semmi sem indul el, és az openconnect kimenet valahogy így fog kinézni:
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 progressEz egyrészt kellemetlen, mert nem volt kapcsolat a VPN-nel, másrészt viszont elvileg egyértelmű, hogyan lehet ezt a problémát orvosolni.
Itt a szerver küldött nekünk egy tanúsítványt, amivel megállapíthatjuk, hogy a kapcsolat nem egy gonosz csalóhoz, hanem a saját cégünk szerveréhez történik, és ez a tanúsítvány a rendszer számára ismeretlen. Ezért nem tudja ellenőrizni, hogy a szerver valódi-e vagy sem. És hát minden esetre leáll.
Ahhoz, hogy az openconnect csatlakozhasson a szerverhez, kifejezetten meg kell adnia, hogy melyik tanúsítvány jöjjön a VPN-kiszolgálótól a —servercert kulcs használatával.
És megtudhatja, hogy a szerver melyik tanúsítványt küldte nekünk közvetlenül az openconnectről. Íme ebből a darabból:
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 progressEzzel a paranccsal megpróbálhatja újra csatlakozni
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comTalán most már működik, és akkor továbbléphet a végére. De személy szerint az Ubunta mutatott nekem egy fügét ebben a formában
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.comA habr.com megoldja, de nem fog tudni odamenni. Az olyan címek, mint a jira.evilcorp.com, egyáltalán nincsenek megoldva.
Hogy mi történt itt, az nem világos számomra. A kísérlet azonban azt mutatja, hogy ha hozzáadja a sort az /etc/resolv.conf fájlhoz
nameserver 192.168.430.534akkor a VPN-en belüli címek varázslatosan elkezdenek feloldódni, és végigsétálhatsz rajtuk, vagyis az, amit a DNS a címek feloldásához keres, az kifejezetten az /etc/resolv.conf fájlban jelenik meg, és nem máshol.
A /etc/resolv.conf módosítása nélkül ellenőrizheti, hogy van-e kapcsolat a VPN-hez, és az működik-e; ehhez csak írja be a böngészőbe, ne a VPN-ből származó erőforrás szimbolikus nevét, hanem annak IP-címét.
Ennek eredményeként két probléma adódik
- Amikor VPN-hez csatlakozik, annak dns-jét nem veszi fel a rendszer
- minden forgalom VPN-en keresztül megy, ami nem teszi lehetővé az internethez való hozzáférést
Megmondom, mit tegyél most, de először egy kis automatizálás.
A jelszó rögzített részének automatikus bevitele
Mostanra valószínűleg már legalább ötször megadta jelszavát, és ez az eljárás már kimerítette. Egyrészt azért, mert a jelszó hosszú, másrészt azért, mert a belépéskor be kell illeszteni egy meghatározott időtartamot
A probléma végső megoldása nem szerepelt a cikkben, de biztos lehet benne, hogy a jelszó fix részét nem kell sokszor beírni.
Tegyük fel, hogy a jelszó rögzített része a rögzített jelszó, a Google Authenticatorból származó része pedig 567 987. A teljes jelszó átadható az openconnectnek szabványos bemeneten keresztül a --passwd-on-stdin argumentummal.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinMostantól folyamatosan visszatérhet az utoljára beírt parancshoz, és ott csak a Google Authenticator egy részét módosíthatja.
A vállalati VPN nem teszi lehetővé az internetezést.
Általánosságban elmondható, hogy nem túl kényelmetlen, ha külön számítógépet kell használnia Habr-ba. A stackoverfow-ból történő másolás-beillesztés képtelensége általában megbéníthatja a munkát, ezért tenni kell valamit.
Valahogy úgy kell megszerveznünk, hogy amikor a belső hálózatról kell hozzáférni egy erőforráshoz, akkor a Linux a VPN-re, ha pedig a Habrra, az internetre menjen.
Az openconnect a vpn elindítása és a kapcsolat létrehozása után egy speciális szkriptet hajt végre, amely a /usr/share/vpnc-scripts/vpnc-script könyvtárban található. Néhány változó bemenetként kerül átadásra a szkriptnek, és ez konfigurálja a VPN-t. Sajnos nem tudtam rájönni, hogyan oszthatom fel a forgalmi áramlásokat a vállalati VPN és az internet többi része között natív szkript segítségével.
Úgy tűnik, a vpn-slice segédprogramot kifejezetten az olyan emberek számára fejlesztették ki, mint én, amely lehetővé teszi, hogy két csatornán keresztül továbbítsa a forgalmat, anélkül, hogy egy tamburintáncolna. Nos, táncolnod kell, de nem kell sámánnak lenned.
Forgalom elkülönítése vpn-slice segítségével
Először is telepítenie kell a vpn-slice-ot, ezt magának kell kitalálnia. Ha van kérdés a kommentekben, erről külön bejegyzést írok. De ez egy szokásos Python program, így nem lehetnek nehézségek. A virtualenv segítségével telepítettem.
Ezután a segédprogramot a -script kapcsolóval kell alkalmazni, jelezve az openconnecthez, hogy a szabványos szkript helyett a vpn-slice-t kell használni.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com A --script egy karakterláncot ad át egy paranccsal, amelyet a szkript helyett kell meghívni. ./bin/vpn-slice - a vpn-slice végrehajtható fájl elérési útja 192.168.430.0/24 - a vpn-ben elérendő címek maszkja. Itt azt értjük, hogy ha a cím 192.168.430-zal kezdődik, akkor az ezzel a címmel rendelkező erőforrást a VPN-en belül kell keresni.
A helyzetnek most már szinte normálisnak kell lennie. Majdnem. Most már ugorhat a Habr-ra, és ip-n keresztül a vállalaton belüli erőforráshoz, de a szimbolikus névvel nem. Ha egyezést ad meg a szimbolikus név és a cím között a gazdagépekben, akkor mindennek működnie kell. És addig dolgozz, amíg az ip meg nem változik. A Linux az IP-től függően most már elérheti az internetet vagy az intranetet. De a cím meghatározásához továbbra is nem vállalati DNS-t használnak.
A probléma ebben a formában is megnyilvánulhat - a munkahelyen minden rendben van, otthon viszont csak IP-n keresztül lehet hozzáférni a belső vállalati erőforrásokhoz. A vállalati Wi-Fi-hez való csatlakozáskor ugyanis a vállalati DNS is használatos, és a VPN-ből származó szimbolikus címek is feloldódnak benne, annak ellenére, hogy VPN használata nélkül továbbra sem lehet ilyen címre menni.
A hosts fájl automatikus módosítása
Ha udvariasan megkérdezik a vpn-slice-t, akkor a VPN felemelése után mehet a DNS-ébe, ott megkeresi a szükséges erőforrások IP-címét szimbolikus nevük szerint, és beírja a hostokba. A VPN kikapcsolása után ezek a címek törlődnek a gazdagépekről. Ehhez szimbolikus neveket kell átadnia a vpn-slice-nek argumentumként. Mint ez.
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 Most mindennek működnie kell az irodában és a strandon is.
Keresse meg az összes aldomain címét a VPN által megadott DNS-ben
Ha kevés cím van a hálózaton belül, akkor a hosts fájl automatikus módosítása meglehetősen jól működik. De ha sok erőforrás van a hálózaton, akkor folyamatosan olyan sorokat kell hozzáadnia a szkripthez, mint a zoidberg.test.evilcorp.com. A zoidberg az egyik tesztpad neve.
De most, hogy egy kicsit megértjük, miért lehet ezt az igényt kiküszöbölni.
Ha a VPN felemelése után az /etc/hosts mappába néz, ezt a sort láthatja
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOMATIKUS LÉTREHOZÁS
És egy új sor került hozzáadásra a resolv.conf fájlhoz. Röviden, a vpn-slice valahogy meghatározta, hogy hol található a vpn DNS-kiszolgálója.
Most meg kell győződnünk arról, hogy az evilcorp.com végződésű domain név IP-címének megtudásához a Linux a vállalati DNS-hez megy, és ha valami másra van szükség, akkor az alapértelmezettre.
Elég sokáig keresgéltem a Google-on, és rájöttem, hogy az Ubuntuban már a dobozból is elérhető ez a funkció. Ez azt jelenti, hogy a dnsmasq helyi DNS-kiszolgálót lehet használni a nevek feloldásához.
Vagyis gondoskodhat arról, hogy a Linux mindig a helyi DNS-kiszolgálóhoz menjen az IP-címekért, amely viszont a tartománynévtől függően megkeresi az IP-t a megfelelő külső DNS-kiszolgálón.
A hálózatokkal és hálózati kapcsolatokkal kapcsolatos minden kezeléséhez az Ubuntu a NetworkManager-t használja, és a grafikus felület például a Wi-Fi kapcsolatok kiválasztásához csak egy előtér.
Meg kell másznunk a konfigurációjában.
- Hozzon létre egy fájlt az /etc/NetworkManager/dnsmasq.d/evilcorp mappában
address=/.evilcorp.com/192.168.430.534
Ügyeljen az evilcorp előtti pontra. Jelzi a dnsmasq-nak, hogy az evilcorp.com összes aldomainjében keresni kell a vállalati DNS-ben.
- Mondja meg a NetworkManagernek, hogy a dnsmasq-ot használja a névfeloldáshoz
A hálózatkezelő konfigurációja az /etc/NetworkManager/NetworkManager.conf fájlban található. Ehhez hozzá kell adnia:
[fő] dns=dnsmasq
- Indítsa újra a NetworkManager programot
service network-manager restartMost, miután csatlakozott egy VPN-hez az openconnect és a vpn-slice használatával, az IP-címet a rendszer a szokásos módon határozza meg, még akkor is, ha nem ad hozzá szimbolikus címeket a vpnslice argumentumához.
Hogyan lehet elérni az egyes szolgáltatásokat VPN-en keresztül
Miután sikerült csatlakoznom a VPN-hez, két napig nagyon boldog voltam, aztán kiderült, hogy ha az irodai hálózaton kívülről csatlakozom a VPN-hez, akkor a levelezés nem működik. A tünet ismerős, nem?
Leveleink a mail.publicevilcorp.com címen találhatók, ami azt jelenti, hogy nem esik a dnsmasq szabálya alá, és a levelezőszerver címét a nyilvános DNS-en keresztül keresik.
Nos, az iroda továbbra is DNS-t használ, amely tartalmazza ezt a címet. Ez az amire gondoltam. Valójában, miután hozzáadta a sort a dnsmasq-hoz
address=/mail.publicevilcorp.com/192.168.430.534
a helyzet mit sem változott. Az ip ugyanaz maradt. mennem kellett dolgozni.
És csak később, amikor jobban beleástam magam a helyzetbe, és egy kicsit megértettem a problémát, egy okos ember mondta el, hogyan kell megoldani. Nem csak így kellett csatlakozni a levelezőszerverhez, hanem VPN-en keresztül
A vpn-slice segítségével megyek át a VPN-en a 192.168.430-zal kezdődő címekre. A levelezőszervernek pedig nem csak szimbolikus címe van, amely nem az evilcorp aldomainje, hanem 192.168.430-zal kezdődő IP-címe sem. És persze nem engedi, hogy az általános hálózatból bárki hozzá jöjjön.
Ahhoz, hogy a Linux keresztülmenjen a VPN-en és a levelezőszerveren, hozzá kell adni a vpn-slice-hez is. Tegyük fel, hogy a levelező címe 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 Szkript a VPN egy argumentummal történő emeléséhez
Mindez persze nem túl kényelmes. Igen, a szöveget elmentheti fájlba, és bemásolhatja a konzolba ahelyett, hogy kézzel gépelné, de ez még mindig nem túl kellemes. A folyamat megkönnyítése érdekében a parancsot becsomagolhatja egy szkriptbe, amely a PATH-ban található. Ezután már csak a Google Authenticatortól kapott kódot kell megadnia
#!/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 Ha a szkriptet a connect~evilcorp~-ba teszed, egyszerűen beírhatod a konzolba
connect_evil_corp 567987De most még mindig nyitva kell tartani a konzolt, amelyben az openconnect fut valamilyen okból
Openconnect futtatása a háttérben
Szerencsére az openconnect szerzői gondoskodtak rólunk, és egy speciális kulcsot adtak a program hátteréhez, amivel a program indulás után a háttérben működik. Ha így futtatod, akkor az indítás után bezárhatod a konzolt
#!/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 Most már csak nem világos, hová kerülnek a rönkök. Általában nincs szükségünk naplókra, de sosem lehet tudni. Az openconnect átirányíthatja őket a syslogba, ahol biztonságban lesznek. hozzá kell adni a –syslog kapcsolót a parancshoz
#!/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 És így kiderül, hogy az openconnect valahol a háttérben működik, és senkit sem zavar, de nem világos, hogyan lehet megállítani. Vagyis természetesen lehet szűrni a ps kimenetet grep segítségével, és keresni egy olyan folyamatot, aminek a neve tartalmazza az openconnectet, de ez valahogy unalmas. Köszönet a szerzőknek, akik ezen is gondolkodtak. Az Openconnectnek van egy -pid-file kulcsa, amellyel utasíthatja az openconnect-et, hogy írja be a folyamatazonosítóját egy fájlba.
#!/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-pidMostantól mindig leállíthat egy folyamatot a paranccsal
kill $(cat ~/vpn-pid)Ha nincs folyamat, a kill átkozódik, de nem dob hibát. Ha a fájl nincs ott, akkor sem történik semmi rossz, így nyugodtan leállíthatja a folyamatot a szkript első sorában.
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-pidMost bekapcsolhatja számítógépét, megnyithatja a konzolt, és futtathatja a parancsot, átadva neki a Google Hitelesítőből származó kódot. A konzol ezután leszögezhető.
VPN-szelet nélkül. Utószó helyett
Nagyon nehéznek bizonyult megérteni, hogyan lehet VPN-szelet nélkül élni. Sokat kellett olvasnom és googlezni. Szerencsére, miután annyi időt töltöttünk egy problémával, a műszaki kézikönyvek és még az openconnect is izgalmas regényként olvasott.
Ennek eredményeként rájöttem, hogy a vpn-slice a natív szkripthez hasonlóan módosítja az útválasztási táblát, hogy elkülönítse a hálózatokat.
Útválasztó táblázat
Leegyszerűsítve, ez egy táblázat az első oszlopban, amely tartalmazza, hogy mivel kell kezdődnie annak a címnek, amelyen a Linux át akar menni, a második oszlopban pedig azt, hogy ezen a címen melyik hálózati adapteren kell keresztülmenni. Valójában több a hangszóró, de ez a lényegen nem változtat.
Az útválasztási tábla megtekintéséhez futtassa az ip route parancsot
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 Itt minden sor felelős azért, hogy hova kell mennie ahhoz, hogy üzenetet küldjön valamilyen címre. Az első annak leírása, hogy hol kell kezdődnie a címnek. Annak megértéséhez, hogyan állapítható meg, hogy a 192.168.0.0/16 azt jelenti, hogy a címnek 192.168-cal kell kezdődnie, meg kell keresnie a google-ban, mi az az IP-címmaszk. A dev után ott van annak az adapternek a neve, amelyre az üzenetet el kell küldeni.
A VPN-hez a Linux virtuális adaptert készített - tun0. A vonal biztosítja, hogy a 192.168-as számmal kezdődő összes cím forgalma átmenjen rajta
192.168.0.0/16 dev tun0 scope link A parancs segítségével megtekintheti az útválasztási tábla aktuális állapotát is útvonal -n (Az IP-címek ügyesen anonimizáltak) Ez a parancs más formában eredményez eredményeket, és általában elavult, de kimenete gyakran megtalálható az interneten található kézikönyvekben, és el kell tudni olvasni.
A Destination és a Genmask oszlopok kombinációjából érthető, hogy egy útvonal IP-címe hol kezdődik. Az IP-cím azon részeit veszik figyelembe, amelyek megfelelnek a Genmask 255-ös számainak, de azokat, ahol 0 van, nem. Vagyis a Destination 192.168.0.0 és a Genmask 255.255.255.0 kombinációja azt jelenti, hogy ha a cím 192.168.0-val kezdődik, akkor a kérés ezen az útvonalon fog haladni. És ha a Destination 192.168.0.0, de a Genmask 255.255.0.0, akkor a 192.168-cal kezdődő címekre vonatkozó kérések ezen az útvonalon haladnak.
Annak érdekében, hogy megtudjam, mit csinál valójában a vpn-slice, úgy döntöttem, hogy megnézem a táblázatok előtti és utáni állapotait.
A VPN bekapcsolása előtt így volt
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 wlp3s0Az openconnect vpn-slice nélküli hívása után ilyen lett
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És miután meghívta az openconnectet a vpn-szelettel kombinálva, mint ez
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 tun0Látható, hogy ha nem használod a vpn-slice-ot, akkor az openconnect kifejezetten azt írja, hogy a konkrétan megjelöltek kivételével minden címet vpn-n keresztül kell elérni.
Pont itt:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Ott mellette egyből egy másik elérési út van feltüntetve, amit akkor kell használni, ha az a cím, amelyen a Linux át akar menni, nem egyezik a táblázat egyik maszkjával sem.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Itt már írták, hogy ebben az esetben szabványos Wi-Fi adaptert kell használni.
Úgy gondolom, hogy a VPN elérési utat használjuk, mert ez az első az útválasztási táblázatban.
És elméletileg, ha eltávolítja ezt az alapértelmezett elérési utat az útválasztási táblából, akkor a dnsmasq openconnect-nek együtt kell biztosítania a normál működést.
megpróbáltam
route del defaultÉs minden működött.
Kérések továbbítása vpn-szelet nélküli levelezőkiszolgálóhoz
De van egy levelezőszerverem is 555.555.555.555 címmel, amit szintén VPN-en keresztül kell elérni. A hozzá vezető útvonalat is kézzel kell hozzáadni.
ip route add 555.555.555.555 via dev tun0És most minden rendben van. Tehát megteheti a vpn-slice nélkül, de jól kell tudnia, mit csinál. Most azon gondolkozom, hogy a natív openconnect szkript utolsó sorához hozzáadom az alapértelmezett útvonal eltávolítását, és a vpn-hez való csatlakozás után hozzáadok egy útvonalat a levelezőhöz, csak hogy kevesebb mozgó alkatrész legyen a bringámban.
Valószínűleg ez az utószó elég lenne ahhoz, hogy valaki megértse, hogyan kell beállítani a VPN-t. De miközben próbáltam megérteni, hogy mit és hogyan csináljak, elég sok ilyen útmutatót olvastam, amelyek a szerzőnek működnek, de valamiért nekem nem, és úgy döntöttem, hogy ideírom az összes talált darabot. Nagyon örülnék egy ilyennek.
Forrás: will.com