Wilt u Linux op het werk gebruiken, maar laat uw bedrijfs-VPN dat niet toe? Dan kan dit artikel helpen, hoewel dat niet zeker is. Ik wil van tevoren waarschuwen dat ik weinig verstand heb van netwerkbeheer, dus het is mogelijk dat ik alles verkeerd heb gedaan. Aan de andere kant is het ook mogelijk dat ik een handleiding kan schrijven die begrijpelijk is voor gewone mensen, dus ik raad aan het te proberen.
Het artikel bevat veel overbodige informatie, maar zonder deze kennis zou ik de problemen die ik onverwacht tegenkwam bij het instellen van de vpn niet hebben kunnen oplossen. Ik denk dat iedereen die probeert deze handleiding toe te passen, problemen zal ondervinden die ik niet had, en ik hoop dat deze overbodige informatie helpt om die problemen zelf op te lossen.
De meeste commando's die in de handleiding worden gebruikt, moeten via sudo worden uitgevoerd, wat voor de beknoptheid is weggelaten. Houd dat in gedachten.
De meeste IP-adressen zijn zwaar obfusceerd, dus als je een adres zoals 435.435.435.435 ziet, zou daar een normaal IP-adres moeten staan dat specifiek is voor jouw situatie.
Ik heb Ubuntu 18.04, maar ik denk dat de handleiding met een paar aanpassingen ook voor andere distributies kan worden toegepast. In deze tekst betekent Linux echter == Ubuntu.
Cisco Connect
Degenen die Windows of MacOS gebruiken, kunnen verbinding maken met ons bedrijfs-VPN via Cisco Connect, waarvoor het gateway-adres moet worden opgegeven en per verbinding een wachtwoord moet worden ingevoerd, dat bestaat uit een vast gedeelte en een code die wordt gegenereerd door Google Authenticator.
In het geval van Linux is het niet gelukt om Cisco Connect te installeren, maar ik vond wel de aanbeveling om openconnect te gebruiken, dat speciaal is gemaakt om Cisco Connect te vervangen.
Openconnect
In Ubuntu zou er een speciale grafische interface voor openconnect moeten zijn, maar die werkte bij mij niet. Misschien is dat maar goed.
In Ubuntu wordt openconnect geĆÆnstalleerd via de pakketbeheerder.
apt install openconnectDirect na de installatie kun je proberen verbinding te maken met de VPN.
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com is het adres van een fictieve VPN.
poxvuibr is de naam van een fictieve gebruiker.
openconnect zal om een wachtwoord vragen, dat, ter herinnering, bestaat uit een vast deel en een code uit Google Authenticator, en daarna zal proberen verbinding te maken met de vpn. Als het gelukt is, gefeliciteerd, je kunt het pijnlijke midden overslaan en naar het onderdeel over het werken van openconnect op de achtergrond gaan. Als het niet gelukt is, kun je doorgaan. Als het bijvoorbeeld gelukt is om verbinding te maken via een gastwifi op het werk, dan is het misschien nog te vroeg om blij te zijn; probeer de procedure thuis opnieuw.
Certificaat
Met een hoge waarschijnlijkheid zal er niets opstarten, en de uitvoer van openconnect zal er als volgt uitzien:
POST https://vpn.evilcorp.com/
Verbonden met 777.777.777.777:443
SSL onderhandeling met vpn.evilcorp.com
Servercertificaat verificatie mislukt: ondertekenaar niet gevonden
Certificaat van VPN-server "vpn.evilcorp.com" is niet goedgekeurd.
Reden: ondertekenaar niet gevonden
Om deze server in de toekomst te vertrouwen, voeg dit misschien toe aan je commandoregel:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Typ 'ja' om te accepteren, 'nee' om af te breken; iets anders om te bekijken: fgets (stdin): Operatie is nu aan de gangAan de ene kant is dit vervelend, omdat er geen VPN-verbinding is tot stand gekomen, maar aan de andere kant is het in principe duidelijk hoe deze situatie te verhelpen.
Hier heeft de server ons een certificaat gestuurd, waarmee we kunnen vaststellen dat de verbinding daadwerkelijk met de server van het moederbedrijf is, en niet met een kwaadwillende oplichter, maar het systeem kent dit certificaat niet. Daarom kan het niet controleren of de server echt is of niet. En daarom stopt het voor alle zekerheid met werken.
Om ervoor te zorgen dat openconnect toch verbinding maakt met de server, moet je expliciet aangeven welk certificaat je van de VPN-server verwacht met de sleutel āservercert
En om te achterhalen welk certificaat de server ons heeft gestuurd, kunnen we gewoon kijken naar wat openconnect heeft afgedrukt. Kijk naar dit stuk:
Om deze server in de toekomst te vertrouwen, voeg dit misschien toe aan je commandoregel:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Typ 'ja' om te accepteren, 'nee' om af te breken; iets anders om te bekijken: fgets (stdin): Operatie is nu aan de gangMet deze opdracht kun je het nog eens proberen om verbinding te maken
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMisschien werkt het nu, dan kun je naar het einde gaan. Maar persoonlijk heeft Ubuntu me dit soort informatie gegeven
POST https://vpn.evilcorp.com/
Verbonden met 777.777.777.777:443
SSL-onderhandeling met vpn.evilcorp.com
Validatie van servercertificaat mislukt: ondertekenaar niet gevonden
Verbonden met HTTPS op vpn.evilcorp.com
XML POST ingeschakeld
Voer uw gebruikersnaam en wachtwoord in.
POST https://vpn.evilcorp.com/
Ontvangen CONNECT-reactie: HTTP/1.1 200 OK
CSTP verbonden. DPD 300, Keepalive 30
Instellen van DTLS mislukt; gebruik in plaats daarvan SSL
Verbonden als 192.168.333.222, met gebruik van SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK antwoorden: Bestand bestaat
/etc/resolvconf/update.d/libc: Waarschuwing: /etc/resolv.conf is geen symbolische link naar /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 zal worden opgelost, maar toegang is niet mogelijk. Adressen zoals jira.evilcorp.com worden helemaal niet opgelost.
Wat hier is gebeurd, is me onduidelijk. Maar het experiment toont aan dat als je de regel toevoegt aan /etc/resolv.conf
nameserver 192.168.430.534de adressen binnen de VPN magisch beginnen op te lossen en je kunt ze bezoeken, dat wil zeggen, datgene wat zoekt hoe adressen op te lossen met DNS, kijkt precies in /etc/resolv.conf, en niet ergens anders.
Dat je verbinding hebt met de VPN en het werkt, kun je zelfs zonder aanpassingen in /etc/resolv.conf bevestigen, het is voldoende om in de browser niet de symbolische naam van de bron uit de VPN in te voeren, maar het IP-adres ervan.
Uiteindelijk zijn er twee problemen
- bij het verbinden met de VPN wordt de DNS daarvan niet opgepakt
- alle verkeer gaat via de VPN, die geen toegang tot internet toestaat
Wat te doen, dat zal ik nu vertellen, maar eerst een beetje automatisering.
Automatische invoer van het vaste deel van het wachtwoord
Tegenwoordig heb je waarschijnlijk het wachtwoord al minstens vijf keer ingevoerd en deze procedure heeft je al behoorlijk vermoeid. Allereerst omdat het wachtwoord lang is, en ten tweede omdat je binnen een vaste tijdsperiode moet invoeren.
De definitieve oplossing van het probleem is niet in het artikel opgenomen, maar je kunt het zo doen dat het vaste deel van het wachtwoord niet vaker dan nodig hoeft te worden ingevoerd.
Laten we zeggen dat het vaste deel van het wachtwoord ā fixedPassword is, en het gedeelte van Google Authenticator 567 987. Het volledige wachtwoord kan openconnect worden doorgegeven via standaardinvoer met behulp van het argument āpasswd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNu kun je voortdurend terugkeren naar het laatst ingevoerde commando en daar alleen het gedeelte van Google Authenticator wijzigen.
De bedrijfs-VPN staat geen internettoegang toe.
Het is eigenlijk best vervelend als je een aparte computer moet gebruiken om naar habr te gaan. Het ontbreken van de mogelijkheid om te kopiƫren en plakken van stackoverfow kan de werkzaamheden compleet stilleggen, dus er moet iets gedaan worden.
We need to somehow organize it so that when accessing a resource from the internal network, Linux goes through VPN, and when accessing Habr, it goes through the internet.
After launching and connecting to the VPN, openconnect runs a special script located at /usr/share/vpnc-scripts/vpnc-script. The script receives some variables as input and handles the VPN setup. Unfortunately, I couldn't figure out how to separate the traffic streams between the corporate VPN and the rest of the internet using the default script.
Apparently, a utility called vpn-slice was specifically developed for people like me, which allows directing traffic through two channels without complicated setups. I mean, there will be some configuration required, but one doesnāt have to be a shaman.
Traffic separation using vpn-slice
First, you'll need to install vpn-slice and figure that out on your own. If there are questions in the comments, I'll write a separate post about it. But it's a regular program written in Python, so it shouldn't be complicated. I installed it using virtualenv.
Next, you need to apply the utility, using the --script key to specify openconnect, indicating that vpn-slice should be used instead of the standard script.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script ".\/bin\/vpn-slice 192.168.430.0\/24 " vpn.evilcorp.com In --script, a command string is passed that needs to be called instead of the script. .\/bin\/vpn-slice ā the path to the vpn-slice executable 192.168.430.0\/24 ā the address mask to be routed through the VPN. This means that if the address starts with 192.168.430, then the resource with that address should be accessed within the VPN.
Now the situation should be almost normal. Almost. Now one can access Habr and the internal resource by IP, but cannot access the internal resource by its symbolic name. If you add the mapping between the symbolic name and address in hosts, everything should work. And continue to work until the IP changes. Linux can now access the internet or the internal network depending on the IP. However, a non-corporate DNS is still used to resolve addresses.
Het probleem kan zich ook op deze manier uiten: op het werk werkt alles normaal, maar thuis kun je alleen via IP toegang krijgen tot interne bedrijfsbronnen. Dit komt omdat wanneer je bent verbonden met het bedrijfs-Wi-Fi, de DNS ook zakelijk is, en in deze DNS worden de symbolische adressen van VPN opgelost, ondanks dat je zonder het gebruik van VPN nog steeds niet op zo'n adres kunt komen.
Automatische wijziging van het hosts-bestand
Als je vpn-slice beleefd vraagt, kan hij na het opzetten van de VPN in zijn DNS gaan kijken, de IP-adressen van de benodigde bronnen vinden op basis van hun symbolische namen en deze in hosts invoeren. Na het uitschakelen van de VPN worden deze adressen uit hosts verwijderd. Hiervoor moeten de symbolische namen als argumenten aan vpn-slice worden doorgegeven. Zo werkt het.
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 Nu zou alles zowel op kantoor als op het strand moeten werken.
Zoek adressen van alle subdomeinen in de DNS die door VPN is verstrekt.
Als er niet veel adressen binnen het netwerk zijn, dan is de benadering met automatische wijziging van het hosts-bestand heel goed werkbaar. Maar als er veel bronnen in het netwerk zijn, zul je voortdurend regels zoals zoidberg.test.evilcorp.com zoidberg moeten toevoegen aan het script, dat is namelijk de naam van een van de testomgevingen.
Maar nu, nu we een beetje begrijpen wat er aan de hand is, kunnen we deze noodzaak wegnemen.
Als je na het opzetten van de VPN naar /etc/hosts kijkt, kun je een regel zoals deze zien.
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
En ook in resolv.conf is een nieuwe regel toegevoegd. Kortom, vpn-slice heeft op de een of andere manier bepaald waar de dns-server voor de VPN zich bevindt.
Nu moeten we ervoor zorgen dat Linux voor het opzoeken van het IP-adres van een domeinnaam die eindigt op evilcorp.com naar de zakelijke DNS gaat, en als je iets anders nodig hebt, naar de standaard.
Ik heb vrij lang gegoogeld en ontdekte dat dergelijke functionaliteit standaard aanwezig is in Ubuntu. Het gaat om de mogelijkheid om een lokale dns-server dnsmasq te gebruiken voor naamresolutie.
Dat wil zeggen, je kunt het zo maken dat Linux altijd naar de lokale dns-server gaat voor IP-adressen, die op zijn beurt, afhankelijk van de domeinnaam, het IP op een bijbehorende externe dns-server zal zoeken.
Om alles te beheren dat verband houdt met netwerken en netwerkverbindingen in Ubuntu, wordt NetworkManager gebruikt, en de grafische interface voor het selecteren van bijvoorbeeld een wifi-verbinding is eenvoudig een frontend daarvoor.
We moeten in zijn configuraties kijken.
- Maak een bestand in /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Let op de punt voor evilcorp. Dit geeft dnsmasq aan dat alle subdomeinen van evilcorp.com in de bedrijfs-DNS moeten worden gezocht.
- Vertel NetworkManager dat dnsmasq moet worden gebruikt voor naamresolutie.
De configuratie van de network-manager bevindt zich in /etc/NetworkManager/NetworkManager.conf. We moeten daar het volgende toevoegen:
[main]
dns=dnsmasq
- Herstart NetworkManager.
service network-manager restartNu, na het verbinden met de VPN met behulp van openconnect en vpn-slice, zal het ip normaal worden bepaald, zelfs zonder symbolische adressen toe te voegen aan de argumenten van vpnslice.
Hoe te verbinden met specifieke services via VPN
Toen ik eenmaal verbinding met de vpn had kunnen maken, was ik twee dagen erg blij, maar toen ontdekte ik dat als ik me niet vanuit het kantoornetwerk met de vpn verbond, de e-mail niet werkte. Een herkenbaar probleem, nietwaar?
Onze e-mail bevindt zich op mail.publicevilcorp.com, wat betekent dat het niet onder de regel in dnsmasq valt, en het adres van de mailserver via publieke DNS wordt gezocht.
In het kantoor wordt echter nog steeds de DNS gebruikt waarin dit adres aanwezig is. Dat dacht ik tenminste. In werkelijkheid veranderde er niets, zelfs niet na het toevoegen van de regel in dnsmasq.
address=/mail.publicevilcorp.com/192.168.430.534
De situatie veranderde niet. Het ip bleef hetzelfde. Ik moest naar het werk gaan.
Pas later, toen ik dieper op de situatie inging en het probleem beter begreep, vertelde een slimme persoon me hoe ik het moest oplossen. Ik moest me niet zomaar met de mailserver verbinden, maar via de vpn.
Ik gebruik vpn-slice om via VPN toegang te krijgen tot adressen die beginnen met 192.168.430. De mailserver is niet alleen geen subdomein van evilcorp, maar zijn ip-adres begint ook niet met 192.168.430. En van het algemene netwerk laat hij natuurlijk niemand toe.
Om ervoor te zorgen dat Linux via VPN en naar de mailserver kan, moet ik deze ook toevoegen aan vpn-slice. Laten we zeggen dat het mailadres 555.555.555.555 is.
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 Script voor het opzetten van VPN met Ć©Ć©n argument.
Dit is natuurlijk niet erg handig. Ja, je kunt de tekst in een bestand opslaan en deze in de console plakken in plaats van deze met de hand in te voeren, maar het is nog steeds niet prettig. Om het proces te vergemakkelijken, kun je het commando in een script zetten dat zich in de PATH bevindt. En dan hoef je alleen maar de code in te voeren die je uit Google Authenticator hebt gekregen.
#!/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 Als je het script in connect~evilcorp~ plaatst, kun je gewoon in de console typen.
connect_evil_corp 567987Maar nu moet je de console waarin openconnect draait wel open houden om een of andere reden.
Openconnect op de achtergrond draaien.
Gelukkig hebben de makers van openconnect aan ons gedacht en een speciale sleutel ābackground toegevoegd, die ervoor zorgt dat het programma na de lancering op de achtergrond werkt. Als je het zo start, kun je de console na de lancering sluiten.
#!/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 Nu is het alleen nog onduidelijk waar de logs naartoe gaan. We hebben de logs eigenlijk niet echt nodig, maar voor het geval dat. Openconnect kan ze omleiden naar syslog, waar ze veilig en intact bewaard blijven. Dit moet worden toegevoegd aan de opdracht met de sleutel ā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 En zo werkt openconnect ergens op de achtergrond en hindert niemand, maar hoe je het moet stoppen is onduidelijk. Je kunt natuurlijk de output filteren met ps en naar het proces zoeken met openconnect in de naam, maar dat is een beetje omslachtig. Bedankt aan de auteurs die hier ook aan gedacht hebben. In openconnect is er een sleutel āpid-file, waarmee je openconnect kunt instrueren om zijn proces-ID in een bestand te schrijven.
#!/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-pidNu kun je het proces altijd beƫindigen met het commando.
kill $(cat ~/vpn-pid)Als het proces er niet is, zal kill een foutmelding geven, maar zal geen fout gooien. Als het bestand er niet is, zal er ook niets ergs gebeuren, dus je kunt het proces gerust in de eerste regel van het script beƫindigen.
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-pidNu kun je de computer aanzetten, de console openen en de opdracht starten, waarbij je de code uit Google Authenticator doorgeeft. De console kun je daarna afsluiten.
Zonder vpn-slice. In plaats van een naschrift.
Begrijpen hoe je zonder vpn-slice moet leven, bleek erg moeilijk. Ik moest veel lezen en googelen. Gelukkig, na zoveel tijd met het probleem, lezen technische handleidingen en zelfs man openconnect als spannende romans.
Uiteindelijk ontdekte ik dat vpn-slice, net als het originele script, de routeringstabel wijzigt om netwerken te splitsen.
Routeringstabel
Simpel gezegd, is het een tabel waarvan de eerste kolom aangeeft waar het adres moet beginnen dat Linux wil bereiken, en de tweede kolom toont via welke netwerkadapter het datadres moet worden bereikt. In werkelijkheid zijn er meer kolommen, maar dat verandert de essentie niet.
Om de routeringstabel te bekijken, moet je de opdracht ip route uitvoeren.
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 Elke regel hier is verantwoordelijk voor waarheen je moet gaan om een bericht naar een bepaald adres te verzenden. De eerste beschrijft waar het adres moet beginnen. Om te begrijpen hoe je moet bepalen dat 192.168.0.0/16 betekent dat het adres moet beginnen met 192.168, moet je Google raadplegen voor wat een IP-adresmasker is. Na dev staat de naam van de adapter waarnaar het bericht gestuurd moet worden.
Voor VPN heeft Linux een virtuele adapter gemaakt ā tun0. De regel die ervoor zorgt dat het verkeer voor alle adressen die beginnen met 192.168 via deze adapter gaat, is
192.168.0.0/16 dev tun0 scope link Je kunt ook de huidige status van de routeringstabel bekijken met het commando route -n (IP-adressen zijn creatief geanonimiseerder) Dit commando geeft resultaten in een andere vorm en is eigenlijk verouderd, maar de uitvoer ervan komt vaak voor in handleidingen op internet en je moet leren deze te lezen.
Waar het IP-adres voor de route moet beginnen, kan worden begrepen uit de combinatie van de kolommen Bestemming en Genmask. De delen van het IP-adres waarvan de cijfers in Genmask 255 zijn, worden meegenomen, terwijl de delen waar 0 staat, dat niet zijn. Dus een combinatie van Bestemming 192.168.0.0 en Genmask 255.255.255.0 betekent dat als het adres begint met 192.168.0, het verzoek via deze route gaat. Maar als de Bestemming 192.168.0.0 is en de Genmask 255.255.0.0, dan gaan verzoeken naar adressen die beginnen met 192.168 via deze route.
Om te begrijpen wat vpn-slice eigenlijk doet, besloot ik de status van de tabellen voor en na te bekijken.
Voor het inschakelen van de VPN was het zo.
route -n
Kernel IP-routeringstabel
Bestemming Gateway Genmask Vlaggen Metric Ref Gebruik Interface
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 wlp3s0Na het aanroepen van openconnect zonder vpn-slice werd het zo.
route -n
Kernel IP routing table
Bestemming Gateway Genmask Vlaggen Metric Ref Gebruik Interface
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 tun0En na het aanroepen van openconnect in combinatie met vpn-slice zo
Kernel IP routing table
Bestemming Gateway Genmask Vlaggen Metric Ref Gebruik Interface
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 tun0Het is duidelijk dat als je geen vpn-slice gebruikt, openconnect expliciet aangeeft dat voor alle adressen, behalve de afzonderlijk opgegeven, moet worden gegaan via vpn.
Hier:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Daar is direct een andere route aangegeven die gebruikt moet worden als het adres waar Linux probeert doorheen te gaan niet overeenkomt met een van de maskers in de tabel.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Hier staat al dat je in dat geval via de standaard wifi-adapter moet gaan.
Ik neem aan dat de route voor VPN wordt gebruikt omdat deze als eerste in de routeringstabel staat.
En theoretisch, als je deze standaardroute uit de routeringstabel verwijdert, zou openconnect in combinatie met dnsmasq normaal moeten functioneren.
Ik heb het geprobeerd
route del defaultEn nu werkt alles.
Routering van verzoeken naar de mailserver zonder vpn-slice
Maar ik heb ook nog een mailserver met het adres 555.555.555.555, waar ik ook via vpn naartoe moet. De route ernaartoe moet ook met de hand worden toegevoegd.
ip route add 555.555.555.555 via dev tun0En nu is alles goed. Dus het kan zonder vpn-slice, maar je moet wel goed weten wat je doet. Ik denk erover om in de laatste regel van het originele openconnect-script het verwijderen van de standaardroute en het toevoegen van de route voor de mailserver na verbinding met vpn toe te voegen, gewoon om het aantal bewegende delen in mijn fiets te verkleinen.
Misschien had iemand genoeg aan deze nawoord om te begrijpen hoe een VPN ingesteld moet worden. Maar terwijl ik probeerde te begrijpen wat en hoe ik het moest doen, heb ik best veel van zulke handleidingen gelezen die bij de auteur werken, maar om de een of andere reden niet bij mij, en besloot ik alle stukjes die ik vond hier toe te voegen. Daar zou ik echt blij mee zijn geweest.
Bron: habr.com
