Szeretné Linuxot használni a munkában, de a vállalati VPN nem engedi? Akkor ez a cikk segíthet, bár nem biztos. Azt szeretném előre jelezni, hogy a hálózatok adminisztrálásához nem értek túl jól, ezért nem kizárt, hogy mindent rosszul csináltam. Másrészt nem kizárt, hogy sikerül olyan útmutatót írnom, ami a hétköznapi emberek számára is érthető, úgyhogy javaslom, próbálja ki.
A cikkben sok felesleges információ található, de ezek nélkül nem tudtam volna megoldani azokat a problémákat, amelyek váratlanul merültek fel a VPN beállításával kapcsolatban. Azt gondolom, hogy bárkinek, aki megpróbálja alkalmazni ezt az útmutatót, lesznek olyan problémái, amik nekem nem voltak, és remélem, hogy ez a felesleges információ segít megoldani ezeket a problémákat.
A legtöbb parancsot, amely az útmutatóban szerepel, sudo-val kell végrehajtani, amelyet a rövidség kedvéért kihagytam. Tartsák ezt észben.
A legtöbb IP-cím erőteljes obfuszkáción ment keresztül, ezért ha olyat lát, mint a 435.435.435.435 – az ott valamilyen normális IP-nek kell lennie, ami az ön esetére specifikus.
Nekem Ubuntu 18.04 van, de úgy gondolom, hogy néhány kisebb módosítással az útmutató más disztribúciókon is alkalmazható. Azonban ebben a szövegben a linux == Ubuntu.
Cisco Connect
Aki Windows vagy MacOS-t használ, csatlakozhat a vállalati VPNünkhoz a Cisco Connect segítségével, amelyhez meg kell adni a gateway címét és minden egyes csatlakozáskor meg kell adni egy jelszót, amely egy fix részből és a Google Authenticator által generált kódból áll.
Linux esetében a Cisco Connect nem indult el, viszont sikerült rátalálni egy ajánlásra, hogy használja az openconnect-et, amelyet kifejezetten a Cisco Connect helyettesítésére készítettek.
Openconnect
Elvileg Ubuntu alatt van egy speciális grafikus felület az openconnect-hez, de nálam nem működött. Talán ez így jobban is van.
Ubuntu alatt az openconnect a csomagkezelőből telepíthető.
apt install openconnectA telepítés után azonnal megpróbálhat csatlakozni a VPN-hez
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com egy kitalált VPN címe
poxvuibr – egy kitalált felhasználónév
Az openconnect megkéri, hogy adja meg a jelszót, ami, emlékeztetek, egy rögzített részből és a Google Authenticator-ból származó kódból áll, majd megpróbál csatlakozni a VPN-hez. Ha sikerült, gratulálok, bátran átugorhatja a fájdalmas középső részt, és áttérhet az openconnect háttérben való működésére. Ha nem működik, folytathatja. Habár ha például sikerült csatlakozni a munkahelyi vendég Wi-Fi-ről, akkor lehet, hogy túl korai az öröm, érdemes megpróbálni megismételni a folyamatot otthonról.
Tanúsítvány
Nagy valószínűséggel semmi sem fog elindulni, és az openconnect kimenete valahogy így néz majd ki:
POST https://vpn.evilcorp.com/
Csatlakozva a 777.777.777.777:443-hoz
SSL tárgyalás a vpn.evilcorp.com-mal
A szerver tanúsítványának ellenőrzése meghiúsult: aláírót nem található
A VPN szerver "vpn.evilcorp.com" tanúsítványa nem teljesítette az ellenőrzést.
Indok: aláírót nem található
A jövőbeli bizalomhoz talán hozzá kell adnia ezt a parancssorához:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Írja be a 'yes' az elfogadáshoz, 'no' a megszakításhoz; bármi más a megtekintéshez: fgets (stdin): Művelet most folyamatbanEgyrészt kellemetlen, mert nem történt VPN kapcsolódás, másrészt viszont érthető, hogyan lehet kezelni ezt a problémát.
Itt a szerver elküldte nekünk a tanúsítványt, amely alapján megállapítható, hogy a csatlakozás valóban a saját vállalatának szerveréhez történik, nem pedig egy gonosz csalóhoz, de a rendszer számára ez a tanúsítvány ismeretlen. Éppen ezért nem tudja ellenőrizni, hogy a szerver valódi-e vagy sem. Ezért minden biztonsági okból leállítja a működést.
Ahhoz, hogy az openconnect mégis csatlakozhasson a szerverhez, egyértelműen meg kell mondani neki, hogy milyen tanúsítványnak kell érkeznie a VPN szervertől a --servercert kulccsal
Azt, hogy milyen tanúsítványt küldött nekünk a szerver, közvetlenül az openconnect által kiírtakból tudhatjuk. Íme, ebből a részből:
A jövőbeli bizalomhoz talán hozzá kell adnia ezt a parancssorához:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Írja be a 'yes' az elfogadáshoz, 'no' a megszakításhoz; bármi más a megtekintéshez: fgets (stdin): Művelet most folyamatbanEzzel a parancssal megpróbálhatjuk újra a csatlakozást
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comLehet, hogy most működik, akkor áttérhetünk a végére. De nekem személy szerint az Ubuntu egy ilyen formában mutatott fityiszt.
POST https://vpn.evilcorp.com/
Csatlakozva a 777.777.777.777:443
SSL-tárgyalás a vpn.evilcorp.com-on
A kiszolgáló tanúsítványának ellenőrzése meghiúsult: aláíró nem található
Csatlakozva HTTPS-en a vpn.evilcorp.com-on
XML POST engedélyezve
Kérjük, adja meg felhasználónevét és jelszavát.
POST https://vpn.evilcorp.com/
KAPCSOLATVÁLASZ kapva: HTTP/1.1 200 OK
CSTP csatlakozva. DPD 300, Keepalive 30
A DTLS beállítása meghiúsult; SSL-t használva helyette
Csatlakozva mint 192.168.333.222, SSL-en keresztül
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK válaszok: A fájl létezik
/etc/resolvconf/update.d/libc: Figyelmeztetés: /etc/resolv.conf nem szimbolikus hivatkozás a /run/resolvconf/resolv.conf-ra/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 feloldódni fog, de belépni nem lehet oda. Az olyan címek, mint a jira.evilcorp.com, egyáltalán nem oldódnak fel.
Ami itt történt, az számomra nem világos. De a kísérlet azt mutatja, hogy ha hozzáadunk egy sort a /etc/resolv.conf-hoz,
nameserver 192.168.430.534akkor a címek a VPN-en belül varázslatos módon fel fognak oldódni, így be lehet járni őket, ami azt jelenti, hogy amit a DNS keres, az valóban a /etc/resolv.conf-t nézi, nem pedig máshol.
Az, hogy a VPN csatlakozik és működik, anélkül is megbizonyosodhatunk, hogy módosítunk a /etc/resolv.conf-on, elegendő, ha a böngészőbe nem egy karakteres nevet, hanem az IP címet írjuk be,
A végeredmény két probléma:
- a VPN-hez való csatlakozáskor nem veszi át annak DNS-ét
- az összes forgalom a VPN-en keresztül megy, amely nem engedi az internetet
Mit tegyünk, arról most beszélek, de először egy kis automatizálásról.
Automatikus beírás a jelszó rögzített részéhez
Eddig valószínűleg már legalább ötször beírtad a jelszót, és ez a folyamat már nagyon fárasztó volt. Először is, mert a jelszó hosszú, másodszor, mert a beírás esetén egy rögzített időintervallumba kell beférni
A probléma végleges megoldása nem került be a cikkbe, de lehet úgy csinálni, hogy a jelszó rögzített részét ne kelljen többször beírni.
Tegyük fel, hogy a jelszó rögzített része — fixedPassword, és a Google Authenticator része 567 987. Az egész jelszót az openconnect segítségével a szabványos bemeneten át lehet adni a --passwd-on-stdin argumentummal.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinMost folyamatosan visszatérhetünk az utoljára beírt parancshoz, és ott csak a Google Authenticator részét változtathatjuk meg.
A vállalati VPN nem engedi az internet használatát.
Valójában nem túl kényelmes, amikor az habr-ra való belépéshez külön gépet kell használnod. Az olyan lehetőségek hiánya, mint a stackoverflow-ról való másolás/beillesztés, valóban megbéníthatja a munkádat, így mindenképpen kell valamit tenni.
Valahogy úgy kell megszervezni, hogy amikor a belső hálózatból kell belépni egy erőforrásra, a Linux VPN-en menjen, de amikor a Habrra van szükség, akkor a nyílt interneten.
Az openconnect a VPN kapcsolódás indítása után végrehajt egy speciális szkriptet, amely a /usr/share/vpnc-scripts/vpnc-script helyen található. A szkriptnek különféle változókat adnak át, és ő végzi el a VPN beállítását. Sajnos nem tudtam kideríteni, hogyan lehet elválasztani a forgalom áramlását a vállalati VPN és a többi internet között a beépített szkripttel.
Nyilvánvalóan az olyanok számára, mint én, kifejlesztettek egy vpn-slice nevű segédprogramot, amely lehetővé teszi, hogy a forgalmat két csatornán irányítsuk, anélkül hogy különösebb nehézségeket okozna. Tehát, elkerülhetetlen, hogy táncoljunk, de a sámánkodás nem kötelező.
Forgalom elválasztása vpn-slice segítségével
Először is telepíteni kell a vpn-slice-ot, amit egyedül vagyok képes megoldani. Ha a hozzászólásokban kérdéseket kapok, írok erről egy külön bejegyzést. De ez egy sima program Pythonban, így nem kellene túl bonyolultnak lennie. Én virtualenv segítségével telepítettem.
Ezután alkalmazni kell a segédprogramot, az --script kulccsal megadva az openconnect-nak, hogy a standard szkript helyett a vpn-slice-ot 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 paraméterben egy parancssor kerül átadásra, amelyet a szkript helyett kell végrehajtani. .\/bin\/vpn-slice — az exec fájl elérési útja; 192.168.430.0\/24 — az IP-címek maszkja, amelyeket VPN-en kell elérni. Itt az értendő, hogy ha az IP-cím a 192.168.430-tól kezdődik, akkor ezt az erőforrást a VPN-en kell keresni.
Most a helyzetnek majdnem normálisnak kell lennie. Majdnem. Most már be lehet lépni a Habrra, illetve a vállalati erőforrásokra IP-n keresztül, de a vállalati erőforrásokra a szimbolikus név alapján nem lehet belépni. Ha a hosts fájlban meghatározzuk a szimbolikus név és az IP cím közötti megfelelést, mindennek működnie kell, és működnie is fog, amíg az IP cím nem változik. A Linux most már képes internetezni vagy bejutni a vállalati hálózatba az IP alapján. De még mindig nem a vállalati DNS-t használja az IP cím meghatározásához.
A probléma másképp is megnyilvánulhat — a munkahelyen minden rendben, de otthon a vállalati forrásokhoz csak IP-n keresztül lehet bejutni. Ennek az az oka, hogy amikor csatlakozol a vállalati Wi-Fi-hez, a DNS is vállalati, és benne a VPN-ből származó szimbolikus címek feloldódnak, annak ellenére, hogy ilyen címeket VPN használata nélkül továbbra sem lehet elérni.
A hosts fájl automatikus módosítása
Ha a vpn-slice-ot udvariasan megkéred, akkor a VPN felépítése után beléphet a DNS-ébe, megtalálhatja az adott források IP-címét a szimbolikus neveik alapján, és felírhatja azokat a hosts fájlba. A VPN leállítása után ezek a címek eltávolításra kerülnek a hosts fájlból. Ehhez a szimbolikus neveket kell átadni a vpn-slice-nak argumentumként. Így.
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 Mostantól mindennek működnie kell a hivatalban és a strandon is.
Címek keresése a VPN által megadott DNS-ben, amely tartalmazza az összes aldomaint
Ha belső hálózaton csak néhány cím van, akkor a hosts fájl automatikus módosításának megközelítése teljesen működőképes. De ha sok forrás van a hálózaton, folyamatosan új sorokat kell majd hozzáadnod a szkripthez, például zoidberg.test.evilcorp.com, mert Zoidberg a tesztkörnyezetek egyike.
De most, hogy egy kicsit jobban megértjük, ezt a szükségességet el lehet távolítani.
Ha a VPN felépítése után megnézed a \/etc\/hosts-ot, valami ilyesmit láthatsz:
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
A resolv.conf fájlba is hozzáadtak egy új sort. Röviden, a vpn-slice valamilyen módon meghatározta, hogy hol található a DNS szerver a VPN számára.
Most szükséges beállítani, hogy az evilcorp.com-ra végződő domainnév IP-címének megismeréséhez a Linux a vállalati DNS-hez forduljon, míg más dolgokhoz az alapértelmezett DNS-hez.
Elég sokáig kerestem a Google-on, és felfedeztem, hogy az Ubuntu már dobozból kiadva is rendelkezik ilyen funkcióval. Arra gondolok, hogy lehetőség van a nevek feloldására a helyi DNS szerver, a dnsmasq használatával.
Tehát be lehet állítani, hogy a Linux mindig a helyi DNS szerverhez forduljon az IP-címekért, amely viszont a domainnevek függvényében fogja keresni az IP-címeket a megfelelő külső DNS szerveren.
A hálózatokkal és hálózati kapcsolatokkal kapcsolatos műveletek kezelésére Ubuntu alatt a NetworkManager használatos, a Wi-Fi kapcsolatok, például a kiválasztásához használt grafikus felület pedig egyszerűen ennek a frontja.
Meg kell vizsgálnunk a konfigurációit.
- Hozzunk létre egy fájlt a /etc/NetworkManager/dnsmasq.d/evilcorp helyen.
address=/.evilcorp.com/192.168.430.534
Figyeljen arra a pontra az evilcorp előtt. Ez jelzi a dnsmasq-nak, hogy minden evilcorp.com aldomain esetében a vállalati DNS-t kell keresnie.
- Mondjuk a NetworkManager-nek, hogy a névfeloldáshoz a dnsmasq-ot kell használni.
A network-manager konfigurációja a /etc/NetworkManager/NetworkManager.conf helyen található. Ezt hozzá kell adnunk:
[main]
dns=dnsmasq
- Indítsuk újra a NetworkManager-t.
service network-manager restartMost, miután csatlakoztunk a VPN-hez az openconnect és a vpn-slice kombinációjával, az IP cím normálisan fog beazonosulni, még akkor is, ha nem adunk karakteres címeket az vpnslice argumentumaihoz.
Hogyan lehet külön szolgáltatásokhoz VPN-en keresztül csatlakozni?
Miután sikerült csatlakozni a VPN-hez, két napig nagyon örültem, aztán kiderült, hogy ha nem az irodai hálózatról csatlakozok a VPN-hez, nem működik az e-mail. Az ismerős tünet, nem igaz?
E-mailünk a mail.publicevilcorp.com-on van, ami nem tartozik a dnsmasq szabályai alá, így a levelezőszerver címe a nyilvános DNS-en keresztül keresendő.
Az irodában viszont továbbra is a DNS-t használjuk, amiben ez a cím szerepel. Pontosan így gondoltam. Valójában azonban a dnsmasq beállításom után,
address=/mail.publicevilcorp.com/192.168.430.534
a helyzet nem változott. Az IP cím változatlan maradt. Muszáj volt dolgozni járnom.
Csak később, amikor mélyebben belemerültem a helyzetbe és kicsit utánanéztem a problémának, egy okos ember mondta meg, hogyan oldhatnám meg. Nem elég csak úgy csatlakozni a levelezőszerverhez, hanem VPN-en keresztül kell.
A vpn-slice-ot használom, hogy VPN-en keresztül azokra a címekre lépjek, amelyek 192.168.430-al kezdődnek. De a levelezőszerver nemcsak hogy nem evilcorp aldomainje, hanem az IP címe is eltér a 192.168.430-tól. Így az általános hálózatból senkit nem enged be.
Ahhoz, hogy a Linux VPN-en keresztül csatlakozzon a levelezőszerverhez, hozzá kell adni a vpn-slice-hoz is. Tegyük fel, hogy a levelezőszerver 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 VPN indító script egy paraméterrel.
Mindez persze nem túl kényelmes. Igen, el lehet menteni a szöveget egy fájlba, és másolni-beilleszteni a konzolba, ahelyett, hogy kézzel írná be, de azért a kellemes érzés elmarad. A folyamat megkönnyítésére a parancsot csomagolhatjuk egy olyan scriptbe, amely a PATH-ban található. Így csak a Google Authenticatorból kapott kódot kell beírni.
#!/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 scriptet a connect~evilcorp~ könyvtárba helyezzük, akkor egyszerűen írhatunk a konzolba.
connect_evil_corp 567987De most is nyitva kell tartani a konzolt, amelyben az openconnect fut.
Az openconnect háttérben való futtatása
Szerencsére az openconnect szerzői gondoskodtak rólunk, és hozzáadták a programhoz a –background különleges kapcsolót, amely lehetővé teszi, hogy a program háttérben fusson a indítás után. Ha így indítjuk, a konzolt az indítás után be is zárhatjuk.
#!/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 az nem világos, hova mennek a logok. A logok igazából nem annyira szükségesek, de sosem lehet tudni. Az openconnect átirányíthatja őket a syslogba, ahol épségben megőrzik őket. Ezt a parancshoz a –syslog kapcsolót kell hozzáadni.
#!/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 Így kiderül, hogy az openconnect ott fut a háttérben, és senkinek nem zavarja, de hogy lehet leállítani, az nem világos. Szóval persze lehet szűrni a ps kimenetet grep-pel, és keresni a folyamatot, amelynek nevében szerepel az openconnect, de ez kicsit fárasztó. Köszönet a szerzőknek, akik erre is gondoltak. Az openconnect rendelkezik egy –pid-file kapcsolóval, amellyel meg lehet utasítani az openconnect-et, hogy írja ki a folyamat azonosí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-pidEzért mindig meg lehet ölni a folyamatot a következő parancs segítségével.
kill $(cat ~/vpn-pid)Ha a folyamat nem létezik, a kill parancs hibát fog jelezni, de nem dob hibát. Ha a fájl nem létezik, akkor sem történik semmi baj, így nyugodtan megölheti a folyamatot a script 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 már csak annyit kell tenni, hogy bekapcsolja a számítógépet, megnyitja a konzolt, és elindítja a parancsot, átadva neki a Google Authenticatorból kapott kódot. A konzolt aztán le lehet állítani.
vpn-slice nélkül. Epilógus helyett.
Megérteni, hogyan lehet élni vpn-slice nélkül, nagyon nehéznek bizonyult. Sokat kellett olvasni és keresni. Szerencsére, amikor ennyi időt töltöttem a problémával, a technikai kézikönyvek és még a man openconnect is izgalmas regényekként olvashatók.
Végül arra jutottam, hogy a vpn-slice, akárcsak az eredeti script, a hálózatok megosztásához módosítja az útválasztási táblázatot.
Útválasztási táblázat
Ez egyszerűen fogalmazva olyan táblázat, amelynek első oszlopában az áll, hogy honnan kell kezdődnie a címnek, amelyen a Linux át akar menni, a második oszlop pedig azt mutatja, hogy melyik hálózati adaptert használja ennek a címnek az elérésére. Valójában több oszlop is van, de ez nem változtat a lényegeken.
Az útválasztási táblázat 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 azt jelzi, hogy hová kell menni, hogy üzenetet küldjünk egy adott címre. Az első a cím kezdő részének leírása. Ahhoz, hogy megértsük, hogyan definiálható, hogy a 192.168.0.0/16 azt jelenti, hogy a címnek 192.168-tól kell kezdődnie, meg kell keresni, hogy mi az ip-cím maszk. A dev után található az adapter neve, amelyre az üzenetet küldeni kell.
A VPN-hez a Linux létrehozott egy virtuális adaptert — tun0. Az a sor felelős, amely biztosítja, hogy a 192.168 kezdetű címek forgalma ezen keresztül haladjon át.
192.168.0.0/16 dev tun0 scope link A jelenlegi útválasztási táblázat állapotát a következő parancs segítségével is meg lehet nézni: route -n (az ip címek ügyesen névtelenítve vannak) Ez a parancs más formátumban adja vissza az eredményeket, és egyébként elavult, de az outputja gyakran megtalálható az internetes kézikönyvekben, és tudni kell olvasni.
Az IP-cím kezdete a Destination és a Genmask oszlopok kombinációjából érthető meg. Azok a részek az IP-címben, ahol a Genmask-ben 255-ös számok vannak, számításba jönnek, míg ahol 0 van, ott nem. Tehát 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-tól kezdődik, akkor a kérés ezen az útvonalon fog menni. Ha a Destination 192.168.0.0, de a Genmask 255.255.0.0, akkor ezen az útvonalon fognak menni a kérdések a 192.168 kezdődő IP címekre.
Annak érdekében, hogy megértsem, pontosan mit csinál a vpn-slice, úgy döntöttem, hogy megnézem az útválasztási táblák állapotát a VPN előtt és után.
A VPN aktiválása előtt ez 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 hívása után, vpn-slice nélkül pedig ez 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 tun0Ami után az openconnect hívása a vpn-slice kombinációjával ilyen lesz
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 tun0Jól látszik, hogy ha nem használjuk a vpn-slice-t, akkor az openconnect világosan jelzi, hogy minden címre, kivéve a kifejezetten megadottakat, a vpn-en kell átmenni.
Itt van:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Ott van egy másik út, amelyet használni kell, ha a Linux által használt cím nem felel meg egyetlen maszkának sem a táblázatban.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Itt már azt írják, hogy ilyen esetben a szabványos wifi adapteren kell átmenni.
Úgy gondolom, hogy a VPN-nek használt út a routing táblában az első, ezért van így.
És elméletileg, ha eltávolítjuk ezt a default útvonalat a routing táblából, akkor a dnsmasq-al az openconnect megfelelő működést kellene, hogy biztosítson.
Megpróbáltam
route del defaultÉs minden működik.
Kérések irányítása a levelezőszerverhez vpn-slice nélkül
De van egy másik levelezőszerverem, amelynek címe 555.555.555.555, amelyre szintén a vpn-en kellene átmenni. Az útvonalat hozzá is manuálisan kell adni.
ip route add 555.555.555.555 via dev tun0Most pedig minden rendben. Tehát meg lehet úszni vpn-slice nélkül, de már jól kell tudni, hogy mit csinálsz. Most azon gondolkodom, ne adjak-e a legutolsó openconnect scriptbe egy default útvonal törlését és a levelezőszerverhez vezető útvonal hozzáadását a vpn-hez való csatlakozás után, csak hogy kevesebb mozgó alkatrészem legyen a biciklimben.
Talán valakinek elegendő lenne ez a bevezető ahhoz, hogy megértse, hogyan kell beállítani a VPN-t. De amíg próbáltam megérteni, hogy mit és hogyan kell tennem, elég sok ilyen útmutatót olvastam, amelyeknél az íróknál működtek, de valamiért nálam nem, és úgy döntöttem, hogy itt összegyűjtöm az összes részt, amit találtam. Nagyon örültem volna, ha valami ilyesmivel találkozom.
Forrás: habr.com
