Wilt u Linux op uw werk gebruiken, maar staat uw zakelijke VPN dit niet toe? Dan kan dit artikel misschien helpen, al is dat niet zeker. Ik wil u van tevoren waarschuwen dat ik de problemen met netwerkbeheer niet goed begrijp, dus het is mogelijk dat ik alles verkeerd heb gedaan. Aan de andere kant is het mogelijk dat ik een gids zo kan schrijven dat deze voor gewone mensen begrijpelijk is, dus ik raad je aan om het te proberen.
Het artikel bevat veel onnodige informatie, maar zonder deze kennis had ik de problemen die mij onverwacht opdoken bij het opzetten van een VPN niet kunnen oplossen. Ik denk dat iedereen die deze handleiding probeert te gebruiken problemen zal krijgen die ik niet had, en ik hoop dat deze extra informatie zal helpen deze problemen zelf op te lossen.
De meeste opdrachten die in deze handleiding worden gebruikt, moeten worden uitgevoerd via sudo, dat vanwege beknoptheid is verwijderd. Onthoud.
De meeste IP-adressen zijn ernstig versluierd, dus als u een adres als 435.435.435.435 ziet, moet daar een normaal IP-adres zijn, specifiek voor uw geval.
Ik heb Ubuntu 18.04, maar ik denk dat de handleiding met kleine wijzigingen op andere distributies kan worden toegepast. Echter, in deze tekst Linux == Ubuntu.
Cisco Connect
Degenen die Windows of MacOS gebruiken, kunnen verbinding maken met onze bedrijfs-VPN via Cisco Connect, dat het gateway-adres moet opgeven en, elke keer dat u verbinding maakt, een wachtwoord moet invoeren dat bestaat uit een vast deel en een code die is gegenereerd door Google Authenticator.
In het geval van Linux kreeg ik Cisco Connect niet aan de praat, maar ik slaagde erin een aanbeveling te googlen om openconnect te gebruiken, speciaal gemaakt om Cisco Connect te vervangen.
Openverbinden
In theorie heeft Ubuntu een speciale grafische interface voor openconnect, maar bij mij werkte het niet. Misschien is het ten goede.
Op Ubuntu wordt openconnect geïnstalleerd vanuit pakketbeheer.
apt install openconnectDirect na de installatie kunt u proberen verbinding te maken met een VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com is het adres van een fictieve VPN
poxvuibr - fictieve gebruikersnaam
openconnect zal u vragen een wachtwoord in te voeren, dat, ik herinner u eraan, bestaat uit een vast gedeelte en een code van Google Authenticator, en vervolgens zal proberen verbinding te maken met de vpn. Als het werkt, gefeliciteerd, kun je het midden overslaan, wat veel pijn doet, en verder gaan met het punt over openconnect dat op de achtergrond draait. Als het niet werkt, kunt u doorgaan. Hoewel als het werkte bij het verbinden, bijvoorbeeld via een gast-Wi-Fi op het werk, het misschien te vroeg is om je te verheugen; je zou moeten proberen de procedure vanuit huis te herhalen.
certificaat
Er is een grote kans dat er niets zal starten, en de openconnect-uitvoer zal er ongeveer zo uitzien:
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 progressAan de ene kant is dit onaangenaam omdat er geen verbinding was met de VPN, maar aan de andere kant is het in principe duidelijk hoe je dit probleem kunt oplossen.
Hier heeft de server ons een certificaat gestuurd, waarmee we kunnen vaststellen dat er verbinding wordt gemaakt met de server van ons oorspronkelijke bedrijf, en niet met een kwaadaardige fraudeur, en dit certificaat is onbekend bij het systeem. En daarom kan ze niet controleren of de server echt is of niet. En dus, voor het geval dat, het niet meer werkt.
Om openconnect verbinding te laten maken met de server, moet u expliciet aangeven welk certificaat van de VPN-server moet komen met behulp van de —servercert sleutel
En u kunt direct achterhalen welk certificaat de server ons heeft gestuurd, van wat openconnect heeft afgedrukt. Hier komt uit dit stuk:
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 progressMet dit commando kunt u opnieuw proberen verbinding te maken
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMisschien werkt het nu, dan kun je doorgaan naar het einde. Maar persoonlijk liet Ubuntu me een vijg in deze vorm zien
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 zal worden opgelost, maar u kunt daar niet heen. Adressen zoals jira.evilcorp.com worden helemaal niet opgelost.
Wat hier gebeurde is mij niet duidelijk. Maar het experiment laat zien dat als je de regel toevoegt aan /etc/resolv.conf
nameserver 192.168.430.534dan zullen de adressen binnen de VPN op magische wijze beginnen op te lossen en kun je er doorheen lopen, dat wil zeggen, wat DNS zoekt om adressen op te lossen, ziet er specifiek uit in /etc/resolv.conf, en niet ergens anders.
U kunt verifiëren dat er een verbinding met de VPN is en dat deze werkt zonder wijzigingen aan te brengen in /etc/resolv.conf; om dit te doen hoeft u in de browser niet de symbolische naam van de bron van de VPN in te voeren, maar het IP-adres ervan
Als gevolg hiervan zijn er twee problemen
- Wanneer u verbinding maakt met een VPN, wordt de DNS ervan niet opgepikt
- al het verkeer verloopt via VPN, waardoor geen toegang tot internet mogelijk is
Ik zal je vertellen wat je nu moet doen, maar eerst een beetje automatisering.
Automatische invoer van het vaste deel van het wachtwoord
Inmiddels heb je waarschijnlijk al minstens vijf keer je wachtwoord ingevoerd en deze procedure heeft je al moe gemaakt. Ten eerste omdat het wachtwoord lang is, en ten tweede omdat je bij het invoeren binnen een vaste tijdsperiode moet passen
De uiteindelijke oplossing voor het probleem stond niet in het artikel, maar je kunt er wel voor zorgen dat het vaste deel van het wachtwoord niet vaak hoeft te worden ingevoerd.
Laten we aannemen dat het vaste deel van het wachtwoord fixedPassword is, en het deel van Google Authenticator 567. Het volledige wachtwoord kan via standaardinvoer aan openconnect worden doorgegeven met behulp van het argument --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNu kunt u voortdurend terugkeren naar het laatst ingevoerde commando en daar slechts een deel van Google Authenticator wijzigen.
Met een bedrijfs-VPN kunt u niet op internet surfen.
Over het algemeen is het niet erg lastig als je een aparte computer moet gebruiken om naar Habr te gaan. Het onvermogen om vanuit Stackoverfow te kopiëren en plakken kan over het algemeen het werk lamleggen, dus er moet iets worden gedaan.
We moeten het op de een of andere manier zo organiseren dat wanneer je toegang wilt krijgen tot een bron van het interne netwerk, Linux naar de VPN gaat, en wanneer je naar Habr moet gaan, het naar internet gaat.
openconnect voert, na het starten en tot stand brengen van een verbinding met vpn, een speciaal script uit, dat zich bevindt in /usr/share/vpnc-scripts/vpnc-script. Sommige variabelen worden als invoer aan het script doorgegeven en het configureert de VPN. Helaas kon ik er niet achter komen hoe ik de verkeersstromen tussen een bedrijfs-VPN en de rest van het internet kon splitsen met behulp van een native script.
Blijkbaar is het hulpprogramma vpn-slice speciaal ontwikkeld voor mensen zoals ik, waarmee je verkeer via twee kanalen kunt sturen zonder met een tamboerijn te dansen. Nou ja, dat wil zeggen, je zult moeten dansen, maar je hoeft geen sjamaan te zijn.
Verkeersscheiding met behulp van vpn-slice
Allereerst zul je vpn-slice moeten installeren, dit zul je zelf moeten uitzoeken. Als er vragen zijn in de reacties, zal ik hierover een aparte post schrijven. Maar dit is een normaal Python-programma, dus er zouden geen problemen moeten zijn. Ik heb geïnstalleerd met behulp van virtualenv.
En dan moet het hulpprogramma worden toegepast met behulp van de schakeloptie -script, waarmee u bij openconnect aangeeft dat u in plaats van het standaardscript vpn-slice moet gebruiken
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script krijgt een string doorgegeven met een commando dat moet worden aangeroepen in plaats van het script. ./bin/vpn-slice - pad naar het vpn-slice uitvoerbare bestand 192.168.430.0/24 - masker van adressen waar naartoe moet worden gegaan in vpn. Hier bedoelen we dat als het adres begint met 192.168.430, de bron met dit adres binnen de VPN moet worden doorzocht
De situatie zou nu bijna normaal moeten zijn. Bijna. Nu kunt u naar Habr gaan en u kunt via ip naar de intra-corporate resource gaan, maar u kunt niet naar de intra-corporate resource gaan via de symbolische naam. Als u een overeenkomst opgeeft tussen de symbolische naam en het adres in hosts, zou alles moeten werken. En werk totdat het IP-adres verandert. Linux heeft nu toegang tot internet of intranet, afhankelijk van het IP-adres. Maar niet-zakelijke DNS wordt nog steeds gebruikt om het adres te bepalen.
Het probleem kan zich ook in deze vorm manifesteren: op het werk is alles in orde, maar thuis heb je alleen via IP toegang tot interne bedrijfsbronnen. Dit komt omdat wanneer je verbonden bent met bedrijfs-Wi-Fi, ook de bedrijfs-DNS wordt gebruikt en daarin symbolische adressen van de VPN worden omgezet, ondanks het feit dat het nog steeds onmogelijk is om naar een dergelijk adres te gaan zonder een VPN te gebruiken.
Automatische wijziging van het hosts-bestand
Als vpn-slice beleefd wordt gevraagd, kan het na het verhogen van de VPN naar zijn DNS gaan, daar de IP-adressen van de benodigde bronnen vinden aan de hand van hun symbolische namen en deze invoeren in hosts. Na het uitschakelen van de VPN worden deze adressen van hosts verwijderd. Om dit te doen, moet u symbolische namen als argumenten aan vpn-slice doorgeven. Soortgelijk.
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 moeten werken, zowel op kantoor als op het strand.
Zoek naar de adressen van alle subdomeinen in de DNS die door de VPN wordt opgegeven
Als er weinig adressen binnen het netwerk zijn, werkt de aanpak van het automatisch wijzigen van het hosts-bestand redelijk goed. Maar als er veel bronnen op het netwerk zijn, moet je constant regels als zoidberg.test.evilcorp.com aan het script toevoegen. Zoidberg is de naam van een van de testbanken.
Maar nu we een beetje begrijpen waarom deze behoefte kan worden geëlimineerd.
Als je, nadat je de VPN hebt verhoogd, in /etc/hosts kijkt, kun je deze regel zien
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
En er is een nieuwe regel toegevoegd aan resolv.conf. Kortom, vpn-slice bepaalde op de een of andere manier waar de dns-server voor de vpn zich bevindt.
Nu moeten we ervoor zorgen dat Linux, om het IP-adres te achterhalen van een domeinnaam die eindigt op evilcorp.com, naar de bedrijfs-DNS gaat, en als er iets anders nodig is, dan naar de standaard-DNS.
Ik heb geruime tijd gegoogled en ontdekte dat dergelijke functionaliteit kant-en-klaar beschikbaar is in Ubuntu. Dit betekent de mogelijkheid om de lokale DNS-server dnsmasq te gebruiken om namen op te lossen.
Dat wil zeggen, je kunt ervoor zorgen dat Linux altijd naar de lokale DNS-server gaat voor IP-adressen, die op zijn beurt, afhankelijk van de domeinnaam, het IP-adres op de overeenkomstige externe DNS-server zoekt.
Om alles wat met netwerken en netwerkverbindingen te maken heeft te beheren, gebruikt Ubuntu NetworkManager, en de grafische interface voor het selecteren van bijvoorbeeld Wi-Fi-verbindingen is slechts een front-end ervan.
We zullen in zijn configuratie moeten klimmen.
- Maak een bestand in /etc/NetworkManager/dnsmasq.d/evilcorp
adres=/.evilcorp.com/192.168.430.534
Besteed aandacht aan het punt voor evilcorp. Het signaleert dnsmasq dat alle subdomeinen van evilcorp.com moeten worden doorzocht in de bedrijfs-DNS.
- Vertel NetworkManager om dnsmasq te gebruiken voor naamomzetting
De netwerkbeheerderconfiguratie bevindt zich in /etc/NetworkManager/NetworkManager.conf. U moet daar toevoegen:
[hoofd] dns=dnsmasq
- Start NetwerkManager opnieuw
service network-manager restartNu, nadat u verbinding heeft gemaakt met een VPN met behulp van openconnect en vpn-slice, wordt het IP-adres normaal bepaald, zelfs als u geen symbolische adressen toevoegt aan de argumenten voor vpnslice.
Toegang krijgen tot individuele services via VPN
Nadat het me lukte om verbinding te maken met de VPN, was ik twee dagen erg blij, en toen bleek dat als ik van buiten het kantoornetwerk verbinding maak met de VPN, mail niet werkt. Het symptoom is bekend, nietwaar?
Onze mail bevindt zich in mail.publicevilcorp.com, wat betekent dat het niet onder de regel in dnsmasq valt en dat het mailserveradres wordt opgezocht via openbare DNS.
Het kantoor gebruikt nog steeds DNS, dat dit adres bevat. Dat is wat ik dacht. Sterker nog, na het toevoegen van de regel aan dnsmasq
adres=/mail.publicevilcorp.com/192.168.430.534
de situatie is helemaal niet veranderd. ip bleef hetzelfde. Ik moest naar mijn werk.
En pas later, toen ik dieper in de situatie verdiepte en het probleem een beetje begreep, vertelde een slimme persoon me hoe ik het moest oplossen. Het was nodig om niet zomaar verbinding te maken met de mailserver, maar via VPN
Ik gebruik vpn-slice om via de VPN naar adressen te gaan die beginnen met 192.168.430. En de mailserver heeft niet alleen een symbolisch adres dat geen subdomein is van evilcorp, hij heeft ook geen IP-adres dat begint met 192.168.430. En natuurlijk laat hij niet toe dat iemand uit het algemene netwerk naar hem toe komt.
Om Linux via de VPN en de mailserver te laten gaan, moet je het ook aan vpn-slice toevoegen. Laten we zeggen dat het adres van de mailer 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 verhogen van VPN met één argument
Dit alles is natuurlijk niet erg handig. Ja, je kunt de tekst in een bestand opslaan en in de console kopiëren en plakken in plaats van hem met de hand te typen, maar het is nog steeds niet erg prettig. Om het proces eenvoudiger te maken, kunt u de opdracht in een script plaatsen dat zich in PATH bevindt. En dan hoeft u alleen de code in te voeren die u van Google Authenticator heeft ontvangen
#!/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 eenvoudig in de console schrijven
connect_evil_corp 567987Maar nu moet je om de een of andere reden nog steeds de console waarop openconnect draait open houden
Openconnect op de achtergrond draaien
Gelukkig hebben de auteurs van openconnect voor ons gezorgd en een speciale sleutel aan de programmaachtergrond toegevoegd, waardoor het programma na de lancering op de achtergrond werkt. Als u het op deze manier uitvoert, kunt u de console na het opstarten 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 gewoon niet duidelijk waar de logboeken naartoe gaan. Over het algemeen hebben we niet echt logboeken nodig, maar je weet maar nooit. openconnect kan ze doorsturen naar syslog, waar ze veilig worden bewaard. u moet de schakeloptie –syslog aan de opdracht toevoegen
#!/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 dus blijkt dat openconnect ergens op de achtergrond werkt en niemand hindert, maar het is niet duidelijk hoe je dit kunt stoppen. Dat wil zeggen, je kunt natuurlijk de ps-uitvoer filteren met behulp van grep en zoeken naar een proces waarvan de naam openconnect bevat, maar dit is op de een of andere manier vervelend. Dank aan de auteurs die hier ook over hebben nagedacht. Openconnect heeft een sleutel -pid-bestand, waarmee u openconnect kunt instrueren om zijn procesidentificatie naar 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 een proces altijd beëindigen met het commando
kill $(cat ~/vpn-pid)Als er geen proces is, zal Kill vloeken, maar geen fout opleveren. Als het bestand er niet is, gebeurt er ook niets ergs, dus je kunt het proces veilig 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 kunt u uw computer aanzetten, de console openen en de opdracht uitvoeren, waarbij u de code van Google Authenticator doorgeeft. Vervolgens kan de console worden vastgespijkerd.
Zonder VPN-stukje. In plaats van een nawoord
Het bleek erg moeilijk om te begrijpen hoe je zonder VPN-stukje moest leven. Ik heb veel moeten lezen en googlen. Gelukkig lezen technische handleidingen en zelfs man openconnect, na zoveel tijd met een probleem te hebben doorgebracht, als spannende romans.
Als resultaat kwam ik erachter dat vpn-slice, net als het native script, de routeringstabel wijzigt om netwerken te scheiden.
Routeringstabel
Simpel gezegd is dit een tabel in de eerste kolom die bevat waar het adres waar Linux doorheen wil gaan moet beginnen, en in de tweede kolom welke netwerkadapter op dit adres moet worden doorgegeven. Sterker nog, er zijn meer sprekers, maar dit verandert niets aan de essentie.
Om de routeringstabel te bekijken, moet u 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 Hier is elke regel verantwoordelijk voor waar u heen moet om een bericht naar een bepaald adres te sturen. De eerste is een beschrijving van waar het adres moet beginnen. Om te begrijpen hoe je kunt bepalen dat 192.168.0.0/16 betekent dat het adres moet beginnen met 192.168, moet je googlen wat een IP-adresmasker is. Na dev staat de naam van de adapter waarnaar het bericht moet worden verzonden.
Voor VPN heeft Linux een virtuele adapter gemaakt: tun0. De lijn zorgt ervoor dat verkeer voor alle adressen die beginnen met 192.168 er doorheen gaat
192.168.0.0/16 dev tun0 scope link U kunt ook de huidige status van de routeringstabel bekijken met behulp van de opdracht route -n (IP-adressen worden slim geanonimiseerd) Deze opdracht levert resultaten op in een andere vorm en is over het algemeen verouderd, maar de uitvoer ervan is vaak te vinden in handleidingen op internet en u moet deze kunnen lezen.
Waar het IP-adres voor een route moet beginnen, kan worden afgeleid uit de combinatie van de kolommen Destination en Genmask. Er wordt rekening gehouden met de delen van het IP-adres die overeenkomen met de nummers 255 in Genmask, maar met de delen waar 0 staat niet. Dat wil zeggen, de combinatie van Destination 192.168.0.0 en Genmask 255.255.255.0 betekent dat als het adres begint met 192.168.0, het verzoek ernaartoe langs deze route zal verlopen. En als Destination 192.168.0.0 maar Genmask 255.255.0.0 is, dan zullen verzoeken aan adressen die beginnen met 192.168 langs deze route gaan
Om erachter te komen wat vpn-slice eigenlijk doet, besloot ik naar de status van de tabellen ervoor en erna te kijken
Voordat ik de VPN inschakelde, was het zo
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 wlp3s0Na het aanroepen van openconnect zonder vpn-slice werd het zo
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 tun0En na het aanroepen van openconnect in combinatie met vpn-slice zoals deze
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 tun0Het is te zien dat als je geen vpn-slice gebruikt, openconnect expliciet schrijft dat alle adressen, behalve de specifiek aangegeven, toegankelijk moeten zijn via vpn.
Hier:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Daar wordt direct een ander pad aangegeven, dat moet worden gebruikt als het adres waar Linux doorheen probeert te komen met geen enkel masker uit de tabel overeenkomt.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Hier staat al geschreven dat u in dit geval een standaard Wi-Fi-adapter moet gebruiken.
Ik geloof dat het VPN-pad wordt gebruikt omdat dit het eerste is in de routeringstabel.
En theoretisch gezien, als je dit standaardpad uit de routeringstabel verwijdert, zou openconnect in combinatie met dnsmasq een normale werking moeten garanderen.
Ik heb geprobeerd
route del defaultEn alles werkte.
Verzoeken routeren naar een mailserver zonder vpn-slice
Maar ik heb ook een mailserver met het adres 555.555.555.555, die ook via VPN moet worden benaderd. De route ernaartoe moet ook handmatig worden toegevoegd.
ip route add 555.555.555.555 via dev tun0En nu is alles in orde. Je kunt dus zonder vpn-slice doen, maar je moet wel goed weten wat je doet. Ik denk er nu over om aan de laatste regel van het native openconnect-script de standaardroute te verwijderen en een route toe te voegen voor de mailer nadat ik verbinding heb gemaakt met de vpn, zodat er minder bewegende delen in mijn fiets zitten.
Waarschijnlijk zou dit nawoord voldoende zijn om iemand te laten begrijpen hoe een VPN moet worden opgezet. Maar terwijl ik probeerde te begrijpen wat en hoe ik moest doen, las ik nogal wat van dergelijke handleidingen die voor de auteur werken, maar om de een of andere reden niet voor mij werken, en ik besloot hier alle stukken die ik vond toe te voegen. Ik zou heel blij zijn met zoiets.
Bron: www.habr.com