Haluatko käyttää Linuxia töissä, mutta yrityksesi VPN ei salli sinua? Sitten tämä artikkeli voi auttaa, vaikka tämä ei ole varmaa. Haluan varoittaa etukäteen, että en ymmärrä verkonhallinnan asioita hyvin, joten on mahdollista, että tein kaiken väärin. Toisaalta on mahdollista, että voin kirjoittaa oppaan niin, että se on tavallisten ihmisten ymmärrettävää, joten suosittelen kokeilemaan sitä.
Artikkeli sisältää paljon tarpeetonta tietoa, mutta ilman tätä tietämystä en olisi pystynyt ratkaisemaan ongelmia, jotka minulle yllättäen ilmestyivät VPN: n asettamisen yhteydessä. Uskon, että jokaisella, joka yrittää käyttää tätä opasta, tulee ongelmia, joita minulla ei ollut, ja toivon, että nämä lisätiedot auttavat ratkaisemaan nämä ongelmat yksinään.
Suurin osa tässä oppaassa käytetyistä komennoista on suoritettava sudon kautta, joka on poistettu lyhyyden vuoksi. Pitää mielessä.
Suurin osa IP-osoitteista on pahasti hämärtynyt, joten jos näet osoitteen, kuten 435.435.435.435, siellä täytyy olla jokin normaali IP-osoite, joka on tapauskohtaista.
Minulla on Ubuntu 18.04, mutta uskon, että pienillä muutoksilla opasta voidaan soveltaa muihin jakeluihin. Tässä tekstissä Linux == Ubuntu.
Cisco Connect
Windows- tai MacOS-käyttäjät voivat muodostaa yhteyden yrityksen VPN:ään Cisco Connectin kautta, jonka on määritettävä yhdyskäytävän osoite ja joka kerta kun muodostat yhteyden, syötettävä salasana, joka koostuu kiinteästä osasta ja Google Authenticatorin luomasta koodista.
Linuxin tapauksessa en saanut Cisco Connectia toimimaan, mutta onnistuin googlettamaan Openconnectin käyttöä suosituksen, joka tehtiin nimenomaan Cisco Connectin korvaamiseksi.
Avaa yhteys
Teoriassa Ubuntussa on erityinen graafinen käyttöliittymä openconnectille, mutta se ei toiminut minulle. Ehkä se on parempaan suuntaan.
Ubuntussa openconnect asennetaan paketinhallinnasta.
apt install openconnectVälittömästi asennuksen jälkeen voit yrittää muodostaa yhteyden VPN-verkkoon
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com on kuvitteellisen VPN:n osoite
poxvuibr - kuvitteellinen käyttäjätunnus
openconnect pyytää sinua syöttämään salasanan, joka, haluan muistuttaa, koostuu kiinteästä osasta ja Google Authenticatorin koodista, ja sitten se yrittää muodostaa yhteyden vpn:ään. Jos se toimii, onnittelut, voit turvallisesti ohittaa keskikohdan, mikä on paljon tuskaa, ja siirtyä siihen kohtaan, että openconnect toimii taustalla. Jos se ei toimi, voit jatkaa. Vaikka se toimi, kun muodostat yhteyden esimerkiksi työpaikalla olevasta vieras-Wi-Fi:stä, voi olla liian aikaista iloita; sinun tulee yrittää toistaa toimenpide kotoa käsin.
Todistus
On suuri todennäköisyys, että mikään ei käynnisty, ja openconnect-lähtö näyttää suunnilleen tältä:
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 progressToisaalta tämä on epämiellyttävää, koska VPN-yhteyttä ei ollut, mutta toisaalta, kuinka tämä ongelma korjataan, on periaatteessa selvää.
Täällä palvelin lähetti meille varmenteen, jonka avulla voimme todeta, että yhteys on muodostettu kotimaisen yhtiömme palvelimeen, ei pahaan huijariin, ja tämä varmenne on järjestelmälle tuntematon. Ja siksi hän ei voi tarkistaa, onko palvelin todellinen vai ei. Ja niin varalta, se lakkaa toimimasta.
Jotta openconnect voi muodostaa yhteyden palvelimeen, sinun on kerrottava sille nimenomaisesti mikä varmenne tulee VPN-palvelimelta käyttämällä —servercert-avainta
Ja voit selvittää, minkä varmenteen palvelin lähetti meille suoraan mistä openconnect tulosti. Tässä tästä palasta:
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 progressTällä komennolla voit yrittää muodostaa yhteyden uudelleen
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comEhkä nyt se toimii, sitten voit siirtyä loppuun. Mutta henkilökohtaisesti Ubunta näytti minulle viikuna tässä muodossa
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 ratkaisee, mutta et voi mennä sinne. Osoitteita, kuten jira.evilcorp.com, ei ole ratkaistu ollenkaan.
Mitä täällä tapahtui, ei ole minulle selvää. Mutta kokeilu osoittaa, että jos lisäät rivin tiedostoon /etc/resolv.conf
nameserver 192.168.430.534silloin VPN:n sisällä olevat osoitteet alkavat ratkaista taianomaisesti ja voit käydä niiden läpi, eli se, mitä DNS etsii osoitteiden ratkaisemiseksi, näyttää nimenomaan tiedostosta /etc/resolv.conf, ei muualta.
Voit varmistaa, että VPN-yhteys on olemassa ja se toimii tekemättä muutoksia tiedostoon /etc/resolv.conf; tehdäksesi tämän, kirjoita selaimeen VPN: n resurssin symbolisen nimen sijaan sen IP-osoitteen.
Seurauksena on kaksi ongelmaa
- Kun muodostat yhteyden VPN-verkkoon, sen dns:ää ei poimita
- kaikki liikenne kulkee VPN:n kautta, mikä ei salli pääsyä Internetiin
Kerron sinulle mitä tehdä nyt, mutta ensin vähän automaatiota.
Salasanan kiinteän osan automaattinen syöttö
Tähän mennessä olet todennäköisesti jo syöttänyt salasanasi vähintään viisi kertaa ja tämä toimenpide on jo väsyttänyt sinut. Ensinnäkin siksi, että salasana on pitkä, ja toiseksi, koska syöttäessäsi sinun täytyy mahtua tiettyyn ajanjaksoon
Lopullista ratkaisua ongelmaan ei ollut artikkelissa, mutta voit varmistaa, että salasanan kiinteää osaa ei tarvitse syöttää monta kertaa.
Oletetaan, että salasanan kiinteä osa on kiinteäPassword ja Google Authenticatorin osa on 567 987. Koko salasana voidaan välittää openconnectiin vakiosyötteen kautta käyttämällä argumenttia --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNyt voit jatkuvasti palata viimeksi syötettyyn komentoon ja muuttaa siellä vain osaa Google Authenticatorista.
Yrityksen VPN ei salli sinun surffata Internetissä.
Yleensä ei ole kovin hankalaa, kun sinun on käytettävä erillistä tietokonetta mennäksesi Habriin. Kyvyttömyys kopioida ja liittää stackoverfow-ohjelmasta voi yleensä halvaannuttaa työn, joten jotain on tehtävä.
Meidän on järjestettävä se jotenkin niin, että kun sinun on käytettävä resurssia sisäisestä verkosta, Linux menee VPN: hen ja kun sinun täytyy mennä Habriin, se menee Internetiin.
openconnect käynnistää ja muodostanut yhteyden vpn:n kanssa suorittaa erityisen komentosarjan, joka sijaitsee /usr/share/vpnc-scripts/vpnc-script. Jotkut muuttujat välitetään komentosarjalle syötteenä, ja se määrittää VPN:n. Valitettavasti en voinut selvittää, kuinka jakaa liikennevirrat yrityksen VPN:n ja muun Internetin välillä käyttämällä alkuperäistä komentosarjaa.
Ilmeisesti erityisesti minun kaltaisilleni ihmisille on kehitetty vpn-slice-apuohjelma, jonka avulla voit lähettää liikennettä kahden kanavan kautta ilman tamburiinin kanssa tanssimista. Eli sinun täytyy tanssia, mutta sinun ei tarvitse olla shamaani.
Liikenteen erottaminen vpn-slice-sovelluksella
Ensinnäkin sinun on asennettava vpn-slice, sinun on selvitettävä tämä itse. Jos kommenteissa on kysyttävää, kirjoitan tästä erillisen postauksen. Mutta tämä on tavallinen Python-ohjelma, joten vaikeuksia ei pitäisi olla. Asensin käyttämällä virtualenv.
Ja sitten apuohjelma on otettava käyttöön käyttämällä -script-kytkintä, mikä osoittaa avataksesi yhteyden, että tavallisen komentosarjan sijaan sinun on käytettävä vpn-slicea
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script välitetään merkkijono, jossa on komento, joka on kutsuttava komentosarjan sijaan. ./bin/vpn-slice - polku vpn-slice-suoritettavaan tiedostoon 192.168.430.0/24 - vpn:n osoitteiden maski. Tässä tarkoitamme, että jos osoite alkaa numerolla 192.168.430, tämän osoitteen resurssi on etsittävä VPN: stä
Tilanteen pitäisi nyt olla lähes normaali. Melkein. Nyt voit mennä Habriin ja voit mennä yrityksen sisäiseen resurssiin ip:llä, mutta et voi mennä yrityksen sisäiseen resurssiin symbolisella nimellä. Jos määrität isännissä olevan symbolisen nimen ja osoitteen välille vastaavuuden, kaiken pitäisi toimia. Ja työskentele kunnes ip vaihtuu. Linux voi nyt käyttää Internetiä tai intranetiä IP-osoitteesta riippuen. Mutta osoitteen määrittämiseen käytetään edelleen muuta kuin yrityksen DNS:ää.
Ongelma voi ilmetä myös tässä muodossa - töissä kaikki on kunnossa, mutta kotona pääsee käsiksi vain yrityksen sisäisiin resursseihin IP:n kautta. Tämä johtuu siitä, että kun olet yhteydessä yrityksen Wi-Fi-verkkoon, käytetään myös yrityksen DNS:ää ja siinä ratkaistaan symboliset osoitteet VPN:stä huolimatta siitä, että tällaiseen osoitteeseen on edelleen mahdotonta mennä ilman VPN: ää.
Hosts-tiedoston automaattinen muokkaus
Jos vpn-slicelta kysytään kohteliaasti, VPN:n nostamisen jälkeen se voi mennä DNS:ään, löytää sieltä tarvittavien resurssien IP-osoitteet symbolisilla nimillään ja syöttää ne isäntäkoneisiin. Kun VPN on poistettu käytöstä, nämä osoitteet poistetaan isännistä. Tätä varten sinun on välitettävä symbolisia nimiä vpn-slicelle argumentteina. Kuten tämä.
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 Nyt kaiken pitäisi toimia sekä toimistossa että rannalla.
Etsi kaikkien aliverkkotunnusten osoitteet VPN:n tarjoamasta DNS:stä
Jos verkossa on vähän osoitteita, hosts-tiedoston automaattinen muokkaaminen toimii melko hyvin. Mutta jos verkossa on paljon resursseja, sinun on jatkuvasti lisättävä rivejä, kuten zoidberg.test.evilcorp.com. zoidberg on yhden testipenkin nimi.
Mutta nyt kun ymmärrämme hieman, miksi tämä tarve voidaan poistaa.
Jos katsot VPN:n nostamisen jälkeen tiedostoon /etc/hosts, näet tämän rivin
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOMAATTILUOTU
Ja uusi rivi lisättiin tiedostoon resolv.conf. Lyhyesti sanottuna vpn-slice määritti jollakin tavalla, missä vpn:n dns-palvelin sijaitsee.
Nyt meidän on varmistettava, että evilcorp.com-päätteisen verkkotunnuksen IP-osoitteen selvittämiseksi Linux siirtyy yrityksen DNS:ään ja jos jotain muuta tarvitaan, niin oletusnimeen.
Googlettelin jonkin aikaa ja huomasin, että tällainen toiminto on saatavilla Ubuntussa heti. Tämä tarkoittaa kykyä käyttää paikallista DNS-palvelinta dnsmasq nimien ratkaisemiseen.
Eli voit varmistaa, että Linux hakee aina IP-osoitteita paikalliselle DNS-palvelimelle, joka puolestaan verkkotunnuksen nimestä riippuen etsii IP:tä vastaavalta ulkoiselta DNS-palvelimelta.
Kaiken verkkoihin ja verkkoyhteyksiin liittyvän hallintaan Ubuntu käyttää NetworkManageria, ja graafinen käyttöliittymä esimerkiksi Wi-Fi-yhteyksien valitsemiseen on vain sen käyttöliittymä.
Meidän on kiivettävä sen kokoonpanossa.
- Luo tiedosto hakemistoon /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Kiinnitä huomiota kohtaan evilcorp. Se ilmoittaa dnsmasq:lle, että kaikki evilcorp.com-aliverkkotunnukset tulee etsiä yrityksen dns:stä.
- Pyydä NetworkManageria käyttämään dnsmasqia nimenselvitykseen
Verkonhallinnan asetukset sijaitsevat hakemistossa /etc/NetworkManager/NetworkManager.conf Sinun on lisättävä sinne:
[pää] dns=dnsmasq
- Käynnistä NetworkManager uudelleen
service network-manager restartNyt, kun olet muodostanut yhteyden VPN:ään käyttämällä openconnectia ja vpn-sliceä, ip määritetään normaalisti, vaikka et lisääisi symbolisia osoitteita vpnslicen argumentteihin.
Kuinka päästä yksittäisiin palveluihin VPN:n kautta
Kun onnistuin muodostamaan yhteyden VPN-verkkoon, olin erittäin onnellinen kaksi päivää, ja sitten kävi ilmi, että jos yhdistän VPN: ään toimistoverkon ulkopuolelta, sähköposti ei toimi. Oire on tuttu, eikö?
Postimme sijaitsee osoitteessa mail.publicevilcorp.com, mikä tarkoittaa, että se ei kuulu dnsmasqin säännön piiriin ja postipalvelimen osoitetta etsitään julkisen DNS:n kautta.
No, toimisto käyttää edelleen DNS:ää, joka sisältää tämän osoitteen. Sitä minä ajattelin. Itse asiassa rivin lisäämisen jälkeen dnsmasqiin
address=/mail.publicevilcorp.com/192.168.430.534
tilanne ei ole muuttunut yhtään. ip pysyi samana. Minun piti mennä töihin.
Ja vasta myöhemmin, kun syvennyin tilanteeseen ja ymmärsin ongelman hieman, yksi fiksu henkilö kertoi minulle, kuinka se ratkaistaan. Postipalvelimeen ei tarvinnut muodostaa yhteyttä vain sillä tavalla, vaan VPN:n kautta
Käytän vpn-slicea mennäkseni VPN:n läpi osoitteisiin, jotka alkavat numerolla 192.168.430. Ja sähköpostipalvelimella ei ole vain symbolista osoitetta, joka ei ole evilcorpin aliverkkotunnus, eikä sillä ole myöskään IP-osoitetta, joka alkaa numerolla 192.168.430. Ja tietenkään hän ei salli kenenkään yleisestä verkostosta tulla luokseen.
Jotta Linux voisi mennä VPN:n läpi ja sähköpostipalvelimelle, sinun on lisättävä se myös vpn-slice-sovellukseen. Oletetaan, että lähettäjän osoite on 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 Komentosarja VPN:n nostamiseksi yhdellä argumentilla
Kaikki tämä ei tietenkään ole kovin kätevää. Kyllä, voit tallentaa tekstin tiedostoon ja kopioida ja liittää sen konsoliin käsin kirjoittamisen sijaan, mutta se ei silti ole kovin miellyttävää. Prosessin helpottamiseksi voit kääriä komennon komentosarjaan, joka sijaitsee polussa PATH. Ja sitten sinun tarvitsee vain syöttää Google Authenticatorista saatu koodi
#!/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 Jos laitat skriptin kohtaan connect~evilcorp~, voit kirjoittaa konsoliin
connect_evil_corp 567987Mutta nyt sinun on silti pidettävä konsoli, jossa openconnect on käynnissä jostain syystä auki
Openconnect käynnissä taustalla
Onneksi openconnectin tekijät pitivät meistä huolta ja lisäsivät ohjelman -taustalle erikoisavaimen, joka saa ohjelman toimimaan taustalla käynnistyksen jälkeen. Jos käytät sitä tällä tavalla, voit sulkea konsolin käynnistämisen jälkeen
#!/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 Nyt ei vain ole selvää, mihin lokit menevät. Yleensä emme todellakaan tarvitse lokeja, mutta et koskaan tiedä. openconnect voi ohjata ne syslogiin, jossa ne pidetään turvassa. sinun on lisättävä -syslog-kytkin komentoon
#!/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 Ja niin käy ilmi, että openconnect toimii jossain taustalla eikä häiritse ketään, mutta ei ole selvää, kuinka se pysäytetään. Eli voit tietysti suodattaa ps-ulostulon grepillä ja etsiä prosessia, jonka nimessä on openconnect, mutta tämä on jotenkin tylsää. Kiitos myös tätä asiaa pohtineille kirjoittajille. Openconnectissa on avain -pid-tiedosto, jolla voit ohjeistaa openconnectin kirjoittamaan prosessin tunnisteen tiedostoon.
#!/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-pidNyt voit aina tappaa prosessin komennolla
kill $(cat ~/vpn-pid)Jos prosessia ei ole, kill kiroaa, mutta ei aiheuta virhettä. Jos tiedostoa ei ole, ei myöskään tapahdu mitään pahaa, joten voit turvallisesti tappaa prosessin komentosarjan ensimmäisellä rivillä.
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-pidNyt voit käynnistää tietokoneesi, avata konsolin ja suorittaa komennon välittämällä sille koodin Google Authenticatorista. Konsoli voidaan sitten naulata.
Ilman VPN-lohkoa. Jälkisanan sijaan
Osoittautui erittäin vaikeaksi ymmärtää, kuinka elää ilman VPN-slicettä. Jouduin lukemaan ja googlettamaan paljon. Onneksi sen jälkeen, kun vietimme niin paljon aikaa ongelman kanssa, tekniset oppaat ja jopa man openconnect lukevat kuin jännittäviä romaaneja.
Tuloksena huomasin, että vpn-slice, kuten alkuperäinen komentosarja, muokkaa reititystaulukkoa erillisiin verkkoihin.
Reititystaulukko
Yksinkertaisesti sanottuna tämä on ensimmäisessä sarakkeessa oleva taulukko, joka sisältää sen osoitteen, jonka Linux haluaa käydä läpi, alkaa, ja toisessa sarakkeessa mikä verkkosovitin tässä osoitteessa. Itse asiassa kaiuttimia on enemmän, mutta tämä ei muuta olemusta.
Jotta voit tarkastella reititystaulukkoa, sinun on suoritettava ip route -komento
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 Täällä jokainen rivi vastaa siitä, minne sinun on mentävä lähettääksesi viestin johonkin osoitteeseen. Ensimmäinen on kuvaus siitä, mistä osoitteen pitäisi alkaa. Ymmärtääksesi kuinka määrittää, että 192.168.0.0/16 tarkoittaa, että osoitteen pitäisi alkaa numerolla 192.168, sinun on googletettava mikä IP-osoitteen peite on. Dev:n jälkeen on sen sovittimen nimi, johon viesti tulee lähettää.
VPN:lle Linux teki virtuaalisen sovittimen - tun0. Linja varmistaa, että kaikkien 192.168-alkuisten osoitteiden liikenne kulkee sen läpi
192.168.0.0/16 dev tun0 scope link Voit myös tarkastella reititystaulukon nykyistä tilaa komennolla reitti -n (IP-osoitteet on näppärästi anonymisoitu) Tämä komento tuottaa tuloksia eri muodossa ja on yleensä vanhentunut, mutta sen tuloste löytyy usein Internetin käsikirjoista ja sinun täytyy pystyä lukemaan se.
Mistä reitin IP-osoitteen pitäisi alkaa, voidaan ymmärtää Destination- ja Genmask-sarakkeiden yhdistelmästä. Ne IP-osoitteen osat, jotka vastaavat Genmaskin numeroita 255, otetaan huomioon, mutta ne, joissa on 0, eivät. Toisin sanoen Destination 192.168.0.0 ja Genmask 255.255.255.0 yhdistelmä tarkoittaa, että jos osoite alkaa numerolla 192.168.0, pyyntö sille kulkee tätä reittiä pitkin. Ja jos kohde on 192.168.0.0 mutta Genmask 255.255.0.0, pyynnöt osoitteisiin, jotka alkavat numerolla 192.168, kulkevat tätä reittiä pitkin
Selvittääkseni mitä vpn-slice todella tekee, päätin tarkastella taulukoiden tiloja ennen ja jälkeen
Ennen VPN:n kytkemistä päälle se oli näin
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 wlp3s0Kun soitettiin openconnectille ilman vpn-slicettä, siitä tuli tällainen
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 tun0Ja kun olet soittanut openconnectille yhdessä vpn-slicen kanssa näin
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 tun0Voidaan nähdä, että jos et käytä vpn-slicea, niin openconnect kirjoittaa nimenomaisesti, että kaikkiin osoitteisiin, paitsi erikseen ilmoitettuihin, on päästävä vpn:n kautta.
tässä:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Siellä sen vieressä näkyy heti toinen polku, jota on käytettävä, jos osoite, jonka kautta Linux yrittää kulkea, ei vastaa mitään taulukon maskia.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Täällä on jo kirjoitettu, että tässä tapauksessa sinun on käytettävä tavallista Wi-Fi-sovitinta.
Uskon, että VPN-polkua käytetään, koska se on ensimmäinen reititystaulukossa.
Ja teoriassa, jos poistat tämän oletuspolun reititystaulukosta, dnsmasq openconnectin kanssa pitäisi varmistaa normaali toiminta.
Minä yritin
route del defaultJa kaikki toimi.
Pyynnön reititys sähköpostipalvelimelle ilman vpn-sliceä
Mutta minulla on myös sähköpostipalvelin, jonka osoite on 555.555.555.555, johon on myös päästävä VPN:n kautta. Reitti siihen on myös lisättävä manuaalisesti.
ip route add 555.555.555.555 via dev tun0Ja nyt kaikki on hyvin. Joten voit tehdä ilman vpn-sliceä, mutta sinun on tiedettävä hyvin mitä teet. Ajattelen nyt, lisäänkö alkuperäisen openconnect-skriptin viimeiselle riville oletusreitin poistamiseksi ja lisäänkö reitin postittajalle vpn-yhteyden muodostamisen jälkeen, jotta pyörässäni olisi vähemmän liikkuvia osia.
Todennäköisesti tämä jälkisana riittäisi jollekulle ymmärtämään, kuinka VPN määritetään. Mutta samalla kun yritin ymmärtää mitä ja miten tehdä, luin aika paljon sellaisia oppaita, jotka toimivat kirjoittajalle, mutta eivät jostain syystä toimi minulle, ja päätin lisätä tähän kaikki löytämäni palaset. Olisin todella iloinen jostain sellaisesta.
Lähde: will.com