Ar norite naudoti „Linux“ darbe, bet jūsų įmonės VPN jums to neleidžia? Tada šis straipsnis gali padėti, nors tai nėra tikras. Iš anksto noriu perspėti, kad nelabai suprantu tinklo administravimo klausimus, todėl gali būti, kad viską padariau ne taip. Kita vertus, gali būti, kad aš galiu parašyti vadovą taip, kad jis būtų suprantamas paprastiems žmonėms, todėl patariu jį išbandyti.
Straipsnyje yra daug nereikalingos informacijos, tačiau be šių žinių nebūčiau galėjęs išspręsti netikėtai man iškilusių problemų nustatant VPN. Manau, kad kiekvienas, kuris bandys naudotis šiuo vadovu, turės problemų, kurių aš neturėjau, ir tikiuosi, kad ši papildoma informacija padės išspręsti šias problemas.
Daugumą šiame vadove naudojamų komandų reikia paleisti naudojant sudo, kuri buvo pašalinta dėl trumpumo. Turėkite omenyje.
Dauguma IP adresų buvo labai užmaskuoti, todėl jei matote adresą, pvz., 435.435.435.435, ten turi būti koks nors įprastas IP, būdingas jūsų atvejui.
Turiu Ubuntu 18.04, bet manau, kad su nedideliais pakeitimais vadovas gali būti pritaikytas kitiems platinimams. Tačiau šiame tekste Linux == Ubuntu.
„Cisco Connect“.
Tie, kurie naudojasi „Windows“ arba „MacOS“, gali prisijungti prie mūsų įmonės VPN per „Cisco Connect“, kuriam reikia nurodyti šliuzo adresą ir kiekvieną kartą prisijungus įvesti slaptažodį, kurį sudaro fiksuota dalis ir „Google Authenticator“ sugeneruotas kodas.
„Linux“ atveju man nepavyko paleisti „Cisco Connect“, bet man pavyko „Google“ rasti rekomendaciją naudoti „openconnect“, sukurtą specialiai „Cisco Connect“ pakeisti.
Atidarykite ryšį
Teoriškai Ubuntu turi specialią grafinę sąsają, skirtą openconnect, bet man ji neveikė. Galbūt tai į gerąją pusę.
„Ubuntu“ sistemoje „openconnect“ įdiegta iš paketų tvarkyklės.
apt install openconnectIškart po įdiegimo galite pabandyti prisijungti prie VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com yra fiktyvaus VPN adresas
poxvuibr – fiktyvus vartotojo vardas
openconnect paprašys įvesti slaptažodį, kurį, priminsiu, sudaro fiksuota dalis ir kodas iš Google Authenticator, tada bandys prisijungti prie vpn. Jei tai veikia, sveikiname, galite saugiai praleisti vidurį, o tai yra labai skausminga, ir pereiti prie taško apie openconnect veikimą fone. Jei tai neveikia, galite tęsti. Nors jei tai pavyko jungiantis, pavyzdžiui, iš svečio „Wi-Fi“ darbe, gali būti per anksti džiaugtis, turėtumėte pabandyti pakartoti procedūrą iš namų.
Pažyma
Didelė tikimybė, kad niekas neprasidės, o „openconnect“ išvestis atrodys maždaug taip:
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 progressViena vertus, tai nemalonu, nes nebuvo ryšio su VPN, tačiau, kita vertus, kaip išspręsti šią problemą, iš esmės aišku.
Čia serveris mums atsiuntė sertifikatą, pagal kurį galime nustatyti, kad jungiamasi su mūsų gimtosios korporacijos serveriu, o ne su piktuoju sukčiu, o šis sertifikatas sistemai nežinomas. Ir todėl ji negali patikrinti, ar serveris yra tikras, ar ne. Ir taip, tik tuo atveju, jis nustos veikti.
Kad „openconnect“ galėtų prisijungti prie serverio, turite aiškiai nurodyti, kuris sertifikatas turi būti gautas iš VPN serverio, naudojant serverio raktą
Ir jūs galite sužinoti, kokį sertifikatą serveris mums atsiuntė tiesiai iš to, ką išspausdino openconnect. Štai iš šio kūrinio:
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 progressSu šia komanda galite bandyti prisijungti dar kartą
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comGalbūt dabar tai veikia, tada galite pereiti prie pabaigos. Bet asmeniškai Ubunta man parodė tokią formą
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 išspręs, bet jūs negalėsite ten patekti. Adresai, tokie kaip jira.evilcorp.com, nėra visiškai išspręsti.
Kas čia atsitiko, man neaišku. Tačiau eksperimentas rodo, kad jei pridėsite eilutę prie /etc/resolv.conf
nameserver 192.168.430.534tada VPN viduje esantys adresai pradės stebuklingai spręstis ir galėsite juos pereiti, ty tai, ko DNS ieško adresams išspręsti, atrodo konkrečiai /etc/resolv.conf, o ne kur nors kitur.
Galite patikrinti, ar yra ryšys su VPN ir jis veikia neatlikus jokių pakeitimų /etc/resolv.conf; norėdami tai padaryti, naršyklėje tiesiog įveskite ne simbolinį VPN ištekliaus pavadinimą, o jo IP adresą.
Dėl to kyla dvi problemos
- Prisijungiant prie VPN, jo dns nepasiimamas
- visas srautas eina per VPN, kuris neleidžia prisijungti prie interneto
Aš jums pasakysiu, ką daryti dabar, bet pirmiausia šiek tiek automatizavimo.
Automatinis fiksuotos slaptažodžio dalies įvedimas
Iki šiol greičiausiai jau įvedėte slaptažodį bent penkis kartus ir ši procedūra jus jau pavargo. Pirma, todėl, kad slaptažodis yra ilgas, ir, antra, todėl, kad įvedant reikia tilpti į fiksuotą laikotarpį
Galutinis problemos sprendimas straipsnyje nebuvo įtrauktas, tačiau galite įsitikinti, kad fiksuotos slaptažodžio dalies nereikia įvesti daug kartų.
Tarkime, kad fiksuotoji slaptažodžio dalis yra „fixPassword“, o „Google Authenticator“ dalis yra 567 987. Visas slaptažodis gali būti perduotas „openconnect“ per standartinę įvestį, naudojant argumentą --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinDabar galite nuolat grįžti prie paskutinės įvestos komandos ir ten pakeisti tik dalį „Google Authenticator“.
Įmonės VPN neleidžia naršyti internete.
Apskritai, tai nėra labai nepatogu, kai norint nuvykti į Habrą reikia naudoti atskirą kompiuterį. Nesugebėjimas nukopijuoti ir įklijuoti iš stackoverfow paprastai gali paralyžiuoti darbą, todėl reikia ką nors padaryti.
Turime kažkaip sutvarkyti taip, kad kai reikia prieiti prie resurso iš vidinio tinklo, Linux eitų į VPN, o kai reikia į Habrą – į internetą.
openconnect, paleidęs ir užmezgęs ryšį su vpn, vykdo specialų scenarijų, kuris yra /usr/share/vpnc-scripts/vpnc-script. Kai kurie kintamieji perduodami scenarijui kaip įvestis ir jis sukonfigūruoja VPN. Deja, aš negalėjau išsiaiškinti, kaip padalyti srautą tarp įmonės VPN ir likusio interneto naudojant vietinį scenarijų.
Matyt, specialiai tokiems žmonėms kaip aš buvo sukurta programa vpn-slice, leidžianti srautą siųsti dviem kanalais nešokant su tamburinu. Na, tai yra, jūs turite šokti, bet jūs neturite būti šamanas.
Eismo atskyrimas naudojant vpn-slice
Pirma, turėsite įdiegti vpn-slice, tai turėsite išsiaiškinti patys. Jei komentaruose kils klausimų, parašysiu apie tai atskirą įrašą. Tačiau tai yra įprasta Python programa, todėl neturėtų kilti jokių sunkumų. Įdiegiau naudodamas virtualenv.
Tada reikia pritaikyti naudingumą naudojant -script jungiklį, nurodantį, kad norint atidaryti ryšį, vietoj standartinio scenarijaus reikia naudoti 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 perduodama eilutė su komanda, kurią reikia iškviesti vietoj scenarijaus. ./bin/vpn-slice – kelias į vpn-slice vykdomąjį failą 192.168.430.0/24 – adresų, į kuriuos reikia eiti vpn, kaukė. Čia turime omenyje, kad jei adresas prasideda 192.168.430, tada ištekliaus su šiuo adresu reikia ieškoti VPN viduje
Dabar situacija turėtų būti beveik normali. Beveik. Dabar galite eiti į Habr ir galite eiti į įmonės vidaus išteklius naudodami ip, bet negalite eiti į įmonės viduje esantį išteklių simboliniu pavadinimu. Jei pagrindiniuose kompiuteriuose nurodysite simbolinio pavadinimo ir adreso atitiktį, viskas turėtų veikti. Ir dirbk, kol ip pasikeis. „Linux“ dabar gali pasiekti internetą arba intranetą, priklausomai nuo IP. Tačiau adresui nustatyti vis tiek naudojamas ne įmonės DNS.
Problema gali pasireikšti ir tokia forma – darbe viskas gerai, bet namuose prie vidinių įmonės resursų galima tik per IP. Taip yra todėl, kad prisijungus prie įmonės „Wi-Fi“ taip pat naudojamas įmonės DNS, o jame išsprendžiami simboliniai adresai iš VPN, nepaisant to, kad tokiu adresu vis tiek neįmanoma patekti nenaudojant VPN.
Automatinis hosts failo modifikavimas
Jei vpn-slice paprašoma mandagiai, tai pakėlus VPN, jis gali eiti į savo DNS, rasti ten reikiamų resursų IP adresus jų simboliniais pavadinimais ir įvesti juos į hostus. Išjungus VPN, šie adresai bus pašalinti iš prieglobos. Norėdami tai padaryti, vpn-slice kaip argumentus turite perduoti simbolinius pavadinimus. Kaip šitas.
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 Dabar viskas turėtų veikti ir biure, ir paplūdimyje.
Ieškokite visų subdomenų adresų VPN pateiktame DNS
Jei tinkle yra nedaug adresų, automatinio hosts failo modifikavimo metodas veikia gana gerai. Bet jei tinkle yra daug išteklių, jums nuolat reikės pridėti eilutes, pvz., zoidberg.test.evilcorp.com, prie scenarijaus zoidberg yra vieno iš bandymų stendų pavadinimas.
Bet dabar, kai šiek tiek suprantame, kodėl šis poreikis gali būti pašalintas.
Jei pakėlus VPN pažvelgsite į /etc/hosts, pamatysite šią eilutę
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOMATINIS KURTA
Ir prie resolv.conf buvo pridėta nauja eilutė. Trumpai tariant, vpn-slice kažkaip nustatė, kur yra vpn DNS serveris.
Dabar turime įsitikinti, kad norėdami sužinoti domeno vardo, kuris baigiasi evilcorp.com, IP adresą, „Linux“ eina į įmonės DNS, o jei reikia dar kažko, tada į numatytąjį.
Aš gana ilgai ieškojau „Google“ ir sužinojau, kad tokia funkcija yra prieinama Ubuntu. Tai reiškia galimybę naudoti vietinį DNS serverį dnsmasq pavadinimams išspręsti.
Tai reiškia, kad galite įsitikinti, kad „Linux“ visada kreipiasi į vietinį DNS serverį, kad gautų IP adresus, o šis, savo ruožtu, priklausomai nuo domeno pavadinimo, ieškos IP atitinkamame išoriniame DNS serveryje.
Norėdami valdyti viską, kas susiję su tinklais ir tinklo ryšiais, „Ubuntu“ naudoja „NetworkManager“, o grafinė sąsaja, skirta, pavyzdžiui, „Wi-Fi“ ryšiams pasirinkti, yra tik jos priekinė dalis.
Mums reikės pakilti į jo konfigūraciją.
- Sukurkite failą /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Atkreipkite dėmesį į tašką priešais evilcorp. Tai signalizuoja dnsmasq, kad visuose evilcorp.com subdomenuose reikia ieškoti įmonės DNS.
- Nurodykite „NetworkManager“ naudoti „dnsmasq“ vardo skyrimui
Tinklo tvarkyklės konfigūracija yra /etc/NetworkManager/NetworkManager.conf. Ten turite pridėti:
[main] dns=dnsmasq
- Iš naujo paleiskite „NetworkManager“.
service network-manager restartDabar, prisijungus prie VPN naudojant openconnect ir vpn-slice, IP bus nustatytas įprastai, net jei prie vpnslice argumentų nepridėsite simbolinių adresų.
Kaip pasiekti atskiras paslaugas per VPN
Po to, kai pavyko prisijungti prie VPN, dvi dienas buvau labai laimingas, o tada paaiškėjo, kad jei prisijungiu prie VPN ne iš biuro tinklo, paštas neveikia. Simptomas pažįstamas, ar ne?
Mūsų paštas yra mail.publicevilcorp.com, o tai reiškia, kad jam netaikoma dnsmasq taisyklė, o pašto serverio adresas ieškomas per viešąjį DNS.
Na, biuras vis dar naudoja DNS, kuriame yra šis adresas. Taip ir maniau. Tiesą sakant, pridėjus eilutę prie dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
situacija nė kiek nepasikeitė. ip liko toks pat. turėjau eiti į darbą.
Ir tik vėliau, kai įsigilinau į situaciją ir šiek tiek supratau problemą, vienas protingas žmogus pasakė, kaip ją išspręsti. Prie pašto serverio reikėjo prisijungti ne šiaip, o per VPN
Naudoju vpn-slice, kad eičiau per VPN adresus, prasidedančius 192.168.430. Ir pašto serveris turi ne tik simbolinį adresą, kuris nėra evilcorp subdomenas, bet ir neturi IP adreso, prasidedančio 192.168.430. Ir, žinoma, jis neleidžia niekam iš bendro tinklo ateiti pas jį.
Kad „Linux“ galėtų pereiti per VPN ir į pašto serverį, jį taip pat reikia įtraukti į „vpn-slice“. Tarkime, siuntėjo adresas yra 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 Scenarijus, skirtas VPN iškelti vienu argumentu
Visa tai, žinoma, nėra labai patogu. Taip, galite įrašyti tekstą į failą ir nukopijuoti-įklijuoti jį į konsolę, o ne įvesti ranka, bet tai vis tiek nėra labai malonu. Kad procesas būtų lengvesnis, komandą galite sudėti į scenarijų, kuris bus PATH. Tada jums reikės tik įvesti kodą, gautą iš 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 Jei įdėjote scenarijų į connect~evilcorp~, galite tiesiog parašyti konsolėje
connect_evil_corp 567987Bet dabar jūs vis tiek turite laikyti konsolę, kurioje veikia openconnect, dėl kokios nors priežasties
Fone veikia openconnect
Laimei, openconnect autoriai pasirūpino mumis ir pridėjo specialų raktą prie programos -fono, dėl kurio programa po paleidimo veikia fone. Jei paleisite taip, paleidę galite uždaryti konsolę
#!/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 Dabar tik neaišku, kur eina rąstai. Apskritai rąstų mums tikrai nereikia, bet niekada negali žinoti. openconnect gali nukreipti juos į syslog, kur jie bus saugūs. prie komandos turite pridėti jungiklį –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 Taigi, pasirodo, kad openconnect veikia kažkur fone ir niekam netrukdo, bet neaišku, kaip tai sustabdyti. Tai yra, jūs, žinoma, galite filtruoti ps išvestį naudodami grep ir ieškoti proceso, kurio pavadinime yra openconnect, bet tai kažkaip nuobodu. Ačiū autoriams, kurie taip pat pagalvojo apie tai. Openconnect turi raktą -pid-file, su kuriuo galite nurodyti openconnect įrašyti savo proceso identifikatorių į failą.
#!/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-pidDabar visada galite nužudyti procesą naudodami komandą
kill $(cat ~/vpn-pid)Jei proceso nėra, nužudymas prakeiks, bet nepadarys klaidos. Jei failo nėra, nieko blogo taip pat nenutiks, todėl galite saugiai nužudyti procesą pirmoje scenarijaus eilutėje.
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-pidDabar galite įjungti kompiuterį, atidaryti konsolę ir paleisti komandą, perduodami jai kodą iš „Google“ autentifikavimo priemonės. Tada galima prikalti konsolę.
Be VPN gabalo. Vietoj posakio
Paaiškėjo, kad labai sunku suprasti, kaip gyventi be VPN gabalo. Teko daug skaityti ir googlinti. Laimei, tiek daug laiko praleidus su problema, techniniai vadovai ir net „man openconnect“ skaitosi kaip jaudinantys romanai.
Dėl to sužinojau, kad vpn-slice, kaip ir vietinis scenarijus, modifikuoja maršruto parinkimo lentelę, kad atskirtų tinklus.
Maršrutizavimo lentelė
Paprasčiau tariant, tai yra pirmame stulpelyje esanti lentelė, kurioje nurodoma, kuo turėtų prasidėti adresas, kurį nori pereiti Linux, ir antrame stulpelyje, per kurį tinklo adapterį šiuo adresu pereiti. Tiesą sakant, garsiakalbių yra daugiau, bet tai nekeičia esmės.
Norėdami peržiūrėti maršruto parinkimo lentelę, turite paleisti komandą 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 Čia kiekviena eilutė yra atsakinga už tai, kur reikia eiti, kad išsiųstumėte pranešimą tam tikru adresu. Pirmasis yra aprašymas, kur turėtų prasidėti adresas. Norint suprasti, kaip nustatyti, kad 192.168.0.0/16 reiškia, kad adresas turi prasidėti 192.168, reikia paieškoti Google, kas yra IP adreso kaukė. Po dev yra adapterio, kuriam turi būti siunčiamas pranešimas, pavadinimas.
VPN, Linux sukūrė virtualų adapterį - tun0. Linija užtikrina, kad per ją eis visų adresų, prasidedančių 192.168, srautas
192.168.0.0/16 dev tun0 scope link Taip pat galite peržiūrėti dabartinę maršruto lentelės būseną naudodami komandą maršrutas -n (IP adresai yra sumaniai anonimizuoti) Ši komanda pateikia kitokios formos rezultatus ir paprastai yra nebenaudojama, tačiau jos išvestis dažnai randama vadovuose internete ir jūs turite mokėti ją perskaityti.
Kur turėtų prasidėti maršruto IP adresas, galima suprasti iš stulpelių Destination ir Genmask derinio. Atsižvelgiama į tas IP adreso dalis, kurios atitinka skaičius 255 Genmaske, bet ne tas, kur yra 0. Tai yra, paskirties vietos 192.168.0.0 ir Genmask 255.255.255.0 derinys reiškia, kad jei adresas prasideda 192.168.0, tada užklausa jam bus pateikta šiuo maršrutu. Ir jei paskirties vieta 192.168.0.0, o Genmask 255.255.0.0, tai užklausos adresais, prasidedančiais 192.168, eis šiuo maršrutu
Norėdamas išsiaiškinti, ką iš tikrųjų veikia vpn-slice, nusprendžiau pažvelgti į lentelių būsenas prieš ir po
Prieš įjungiant VPN buvo taip
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 wlp3s0Paskambinus į openconnect be vpn-slice tapo taip
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 tun0Ir paskambinus openconnect kartu su vpn-slice taip
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 tun0Matyti, kad jei nenaudojate vpn-slice, tai openconnect aiškiai rašo, kad visi adresai, išskyrus konkrečiai nurodytus, turi būti pasiekiami per vpn.
Štai čia:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Ten, šalia, iš karto nurodomas kitas kelias, kurį reikia naudoti, jei adresas, kuriuo bando pereiti Linux, nesutampa su jokia lentelės kauke.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Čia jau parašyta, kad tokiu atveju reikia naudoti standartinį Wi-Fi adapterį.
Manau, kad VPN kelias naudojamas, nes jis yra pirmasis maršruto parinkimo lentelėje.
Ir teoriškai, jei pašalinsite šį numatytąjį kelią iš maršruto lentelės, tada kartu su dnsmasq openconnect turėtų užtikrinti normalų veikimą.
Aš bandžiau
route del defaultIr viskas veikė.
Užklausų nukreipimas į pašto serverį be vpn-slice
Bet aš taip pat turiu pašto serverį adresu 555.555.555.555, kurį taip pat reikia pasiekti per VPN. Maršrutą iki jo taip pat reikia pridėti rankiniu būdu.
ip route add 555.555.555.555 via dev tun0O dabar viskas gerai. Taigi galite apsieiti be vpn-slice, bet turite gerai žinoti, ką darote. Dabar galvoju apie tai, kaip į paskutinę vietinio atvirojo ryšio scenarijaus eilutę įtraukti numatytąjį maršrutą ir pridėti siuntėjo maršrutą prisijungus prie VPN, kad mano dviratyje būtų mažiau judančių dalių.
Tikriausiai šio posakio užtektų, kad kas nors suprastų, kaip nustatyti VPN. Bet kol bandžiau suprasti, ką ir kaip daryti, perskaičiau gana daug tokių vadovų, kurie tinka autoriui, bet kažkodėl netinka man, ir nusprendžiau čia pridėti visus kūrinius, kuriuos radau. Labai apsidžiaugčiau dėl tokio dalyko.
Šaltinis: www.habr.com