Re: OpenVPN en "dns leakage"
On Wed, 26 Feb 2020 16:41:17 +0100 Paul van der Vlis wrote: > Jawel, Networkmanager doet dat. > > > Vandaar dat ik er > > een link van zou maken die naar een andere dir wijst. > > Het overschrijft dan het file in die ander dir lijkt me. Of hij zet een file neer ipv die symlink > > Brr, dat ding. Networkdestroyer bedoel je. Maar als je de boel > > met chattr te lijf gaat, crasht dat ding dan niet? Want zoiets > > verwacht-ie natuurlijk niet... > > Inderdaad, dat ding bedoel ik. Gebruik ik normaal alleen op laptops, > maar die Freedombox-software gebruikt het nogal intensief dus vandaar. > > En nee, het crashed niet, geeft zelfs geen melding in de logs dat > schrijven niet kan. Tsja... > Ik vond dit overigens nog: > https://github.com/wknapik/vpnfailsafe Ja, ik zou dan toch liever m'n eigen scripts gebruiken en policy routing gebruiken, dan hoef je niet zo moeilijk te doen. Zodra de tunnel opkomt gewoon een andere routetabel kiezen en die heeft z'n eigen [ip|nf]tables scripts. Overigens draait openvpn bij hen wel als root, ik ben daar niet zo'n voorstander van. Misschien is het handig het eindpunt van de tunnel in /etc/hosts te zetten, als de DNS het een keer om wat voor reden het niet doet kun je wel een tunnel opbouwen. Maar waarom draai je niet unbound die direct de rootservers benadert? Zo vindt de provider het niet in de logs van de DNS, maar met een dump kun je altijd zien wat er gevraagd wordt, maar dat zie je aan het eind van de tunnel ook. Dus wat win je ermee? Overigens is dat ge-VPN ook maar een hype. Mensen denken dat ze veilig zitten. Maar wie garandeert dat? Zonder vpn ziet je provider het, met een vpn ziet de vpn aanbieder het. Een vpn is niets meer dan een virtueel stuk draad die je ergens in een switch steekt. Als je iets wilt uitvreten gebruik dan Tor. En dan nog. R. -- richard lucassen http://contact.xaq.nl/
Re: OpenVPN en "dns leakage"
Op 26-02-2020 om 14:07 schreef Richard Lucassen: > On Wed, 26 Feb 2020 13:35:55 +0100 > Paul van der Vlis wrote: > >>>>> Dat is wel erg bot. >> >> Het is bot, maar geeft niet eens een foutmelding in de logs. >> En wat is er erg aan bot? > > Nou, zelfs root krijgt dan een permission denied, en als resolvconf > verwijderd is zou niemand er meer aan mogen zitten. Jawel, Networkmanager doet dat. > Vandaar dat ik er > een link van zou maken die naar een andere dir wijst. Het overschrijft dan het file in die ander dir lijkt me. >>> ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf >> >> Networkmanager heeft de neiging om /etc/resolv.conf te veranderen. Het >> zet er bij IPv6 een lokale nameserver bij die DNS-leaks kan geven. In >> de praktijk doet hij dat niet, maar als de andere uitvalt wel. > > Brr, dat ding. Networkdestroyer bedoel je. Maar als je de boel > met chattr te lijf gaat, crasht dat ding dan niet? Want zoiets > verwacht-ie natuurlijk niet... Inderdaad, dat ding bedoel ik. Gebruik ik normaal alleen op laptops, maar die Freedombox-software gebruikt het nogal intensief dus vandaar. En nee, het crashed niet, geeft zelfs geen melding in de logs dat schrijven niet kan. >>> Ja ok, het gaat dus niet om security maar om het verbergen van >>> illegale activiteiten :-) >> >> Een vertrouwde DNS server willen gebruiken is ook security. > > Maar ook van die resolver kun je volgen wat-ie opvraagt... > >> Er zijn vele mensen die een VPN willen gebruiken om verschillende >> redenen, en dat DNS-leak ergerde mij. In de GUI clients schijnt het >> opgelost, maar op de commandline gaat het niet goed. > > Huh? Dat lijkt me onlogisch. Of heeft Poettering weer iets "gefixt"? Goed mogelijk... Ik vond dit overigens nog: https://github.com/wknapik/vpnfailsafe Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: OpenVPN en "dns leakage"
On Wed, 26 Feb 2020 13:35:55 +0100 Paul van der Vlis wrote: > >>> Dat is wel erg bot. > > Het is bot, maar geeft niet eens een foutmelding in de logs. > En wat is er erg aan bot? Nou, zelfs root krijgt dan een permission denied, en als resolvconf verwijderd is zou niemand er meer aan mogen zitten. Vandaar dat ik er een link van zou maken die naar een andere dir wijst. > > ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf > > Networkmanager heeft de neiging om /etc/resolv.conf te veranderen. Het > zet er bij IPv6 een lokale nameserver bij die DNS-leaks kan geven. In > de praktijk doet hij dat niet, maar als de andere uitvalt wel. Brr, dat ding. Networkdestroyer bedoel je. Maar als je de boel met chattr te lijf gaat, crasht dat ding dan niet? Want zoiets verwacht-ie natuurlijk niet... > > Ja ok, het gaat dus niet om security maar om het verbergen van > > illegale activiteiten :-) > > Een vertrouwde DNS server willen gebruiken is ook security. Maar ook van die resolver kun je volgen wat-ie opvraagt... > Er zijn vele mensen die een VPN willen gebruiken om verschillende > redenen, en dat DNS-leak ergerde mij. In de GUI clients schijnt het > opgelost, maar op de commandline gaat het niet goed. Huh? Dat lijkt me onlogisch. Of heeft Poettering weer iets "gefixt"? -- richard lucassen http://contact.xaq.nl/
Re: OpenVPN en "dns leakage"
Op 26-02-2020 om 13:18 schreef Richard Lucassen: > On Wed, 26 Feb 2020 12:11:37 +0100 > Paul van der Vlis wrote: > >>> Dat is wel erg bot. Het is bot, maar geeft niet eens een foutmelding in de logs. En wat is er erg aan bot? > Je kunt openvpn ook de resolv.conf laten >>> aanpassen, up is niet zo'n probleem (dan is-ie nog root), down heb >>> je sudo voor nodig. >> >> Heb je daar een mooi scriptje voor? > > Nee, ik gebruik die optie nooit, alhoewel ja, om routes toe te voegen of > policy routing aan te sturen, maar dat hoeft alleen maar bij het "up" > komen van het device want als het device verdwijnt ruimt de kernel de > bijbehorende routes op. > > In de config: > > up /path/to/script start > down /path/to/script stop > > Het "up" script draait als "root", maar bij "down" moet je wel sudo > gebruiken omdat de tunnel default dan onder de user nobody draait (ik > zou daar een aparte user voor nemen iig) > > Je zou simpelweg een > > /etc/openvpn/resolv/resolv-ovpn.conf > /etc/openvpn/resolv/resolv-default.conf > > kunnen aanmaken en daar in die specifieke dir /etc/openvpn/resolv (die > writable is voor de user openvpn) een "ln -sf resolv.conf" op > kunnen loslaten door dat script dat openvpn aanstuurt. En dan maak > je als root in de /etc/ dir een link naar > > ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf Networkmanager heeft de neiging om /etc/resolv.conf te veranderen. Het zet er bij IPv6 een lokale nameserver bij die DNS-leaks kan geven. In de praktijk doet hij dat niet, maar als de andere uitvalt wel. >>> En je vertrouwt de DNS aan de andere kant van de tunnel wel? >> >> Dat is mijn eigen DNS-server. Op het moment nog DNSmasq die verwijst >> naar mijn eigen DNS-servers maar ik wil er Bind9 van maken wat >> rechtsstreeks bij de root-servers navraagt. > > Ik zou unbound gebruiken, dat is een recursive only resolver. Maar dat > terzijde. > >>> Verplaats je niet gewoon het probleem? >> >> Iemand wil vaak een VPN omdat hij films download o.i.d. Op deze manier >> kan de ISP niet meer zien wat voor naam je resolved. >> >> En als er een andere nameserver gebruikt zou worden dan ziet die ook >> alleen het IP van de VPN. > > Ja ok, het gaat dus niet om security maar om het verbergen van illegale > activiteiten :-) Een vertrouwde DNS server willen gebruiken is ook security. Er zijn vele mensen die een VPN willen gebruiken om verschillende redenen, en dat DNS-leak ergerde mij. In de GUI clients schijnt het opgelost, maar op de commandline gaat het niet goed. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: OpenVPN en "dns leakage"
On Wed, 26 Feb 2020 12:11:37 +0100 Paul van der Vlis wrote: > > Dat is wel erg bot. Je kunt openvpn ook de resolv.conf laten > > aanpassen, up is niet zo'n probleem (dan is-ie nog root), down heb > > je sudo voor nodig. > > Heb je daar een mooi scriptje voor? Nee, ik gebruik die optie nooit, alhoewel ja, om routes toe te voegen of policy routing aan te sturen, maar dat hoeft alleen maar bij het "up" komen van het device want als het device verdwijnt ruimt de kernel de bijbehorende routes op. In de config: up /path/to/script start down /path/to/script stop Het "up" script draait als "root", maar bij "down" moet je wel sudo gebruiken omdat de tunnel default dan onder de user nobody draait (ik zou daar een aparte user voor nemen iig) Je zou simpelweg een /etc/openvpn/resolv/resolv-ovpn.conf /etc/openvpn/resolv/resolv-default.conf kunnen aanmaken en daar in die specifieke dir /etc/openvpn/resolv (die writable is voor de user openvpn) een "ln -sf resolv.conf" op kunnen loslaten door dat script dat openvpn aanstuurt. En dan maak je als root in de /etc/ dir een link naar ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf > > En je vertrouwt de DNS aan de andere kant van de tunnel wel? > > Dat is mijn eigen DNS-server. Op het moment nog DNSmasq die verwijst > naar mijn eigen DNS-servers maar ik wil er Bind9 van maken wat > rechtsstreeks bij de root-servers navraagt. Ik zou unbound gebruiken, dat is een recursive only resolver. Maar dat terzijde. > > Verplaats je niet gewoon het probleem? > > Iemand wil vaak een VPN omdat hij films download o.i.d. Op deze manier > kan de ISP niet meer zien wat voor naam je resolved. > > En als er een andere nameserver gebruikt zou worden dan ziet die ook > alleen het IP van de VPN. Ja ok, het gaat dus niet om security maar om het verbergen van illegale activiteiten :-) -- richard lucassen http://contact.xaq.nl/
Re: OpenVPN en "dns leakage"
Op 26-02-2020 om 11:39 schreef Richard Lucassen: > On Wed, 26 Feb 2020 11:27:18 +0100 > Paul van der Vlis wrote: > >> Wat ik uiteindelijk maar heb gedaan is het volgende: >> Ik heb resolvconf verwijderd. >> Ik heb /etc/resolv.conf niet te wijzigen gemaakt met: >> chattr +i /etc/resolv.conf > > Dat is wel erg bot. Je kunt openvpn ook de resolv.conf laten aanpassen, > up is niet zo'n probleem (dan is-ie nog root), down heb je sudo voor > nodig. Heb je daar een mooi scriptje voor? >> Tja, nu is alleen de nameserver wel statisch geworden, niet helemaal >> wat ik wou. Ik gebruik het VPN-IP van VPN-server als nameserver. >> >> Geen DNS leakage meer volgens https://www.dnsleaktest.com/ . > > En je vertrouwt de DNS aan de andere kant van de tunnel wel? Dat is mijn eigen DNS-server. Op het moment nog DNSmasq die verwijst naar mijn eigen DNS-servers maar ik wil er Bind9 van maken wat rechtsstreeks bij de root-servers navraagt. > Verplaats je niet gewoon het probleem? Iemand wil vaak een VPN omdat hij films download o.i.d. Op deze manier kan de ISP niet meer zien wat voor naam je resolved. En als er een andere nameserver gebruikt zou worden dan ziet die ook alleen het IP van de VPN. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: OpenVPN en "dns leakage"
On Wed, 26 Feb 2020 11:27:18 +0100 Paul van der Vlis wrote: > Wat ik uiteindelijk maar heb gedaan is het volgende: > Ik heb resolvconf verwijderd. > Ik heb /etc/resolv.conf niet te wijzigen gemaakt met: > chattr +i /etc/resolv.conf Dat is wel erg bot. Je kunt openvpn ook de resolv.conf laten aanpassen, up is niet zo'n probleem (dan is-ie nog root), down heb je sudo voor nodig. > Tja, nu is alleen de nameserver wel statisch geworden, niet helemaal > wat ik wou. Ik gebruik het VPN-IP van VPN-server als nameserver. > > Geen DNS leakage meer volgens https://www.dnsleaktest.com/ . En je vertrouwt de DNS aan de andere kant van de tunnel wel? Verplaats je niet gewoon het probleem? R. -- richard lucassen http://contact.xaq.nl/
Re: OpenVPN en "dns leakage"
Op 24-02-2020 om 18:50 schreef Paul van der Vlis: > Hoi, > > Ik probeer OpenVPN zo op te zetten dat er geen "dns leakage" is. > > Als ik de VPN start dan wordt netjes de dns gewijzigd in > /etc/resolv.conf door update-resolv-conf. Echter, er wordt hier alleen > een DNS toegevoegd, de oude is er ook nog. Ik wil dat alleen de DNS > wordt gebruikt die door OpenVPN wordt gepushed. > > Heeft iemand hier een mooie CLI oplossing voor? > > Het gaat om een Freedombox, dit gebruikt networkmanager en firewalld. > Ik heb "resolvconf" geinstalleerd om update-resolv-conf werkend te > krijgen, dit was niet standaard geinstalleerd. Wat ik uiteindelijk maar heb gedaan is het volgende: Ik heb resolvconf verwijderd. Ik heb /etc/resolv.conf niet te wijzigen gemaakt met: chattr +i /etc/resolv.conf Tja, nu is alleen de nameserver wel statisch geworden, niet helemaal wat ik wou. Ik gebruik het VPN-IP van VPN-server als nameserver. Geen DNS leakage meer volgens https://www.dnsleaktest.com/ . Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
OpenVPN en "dns leakage"
Hoi, Ik probeer OpenVPN zo op te zetten dat er geen "dns leakage" is. Als ik de VPN start dan wordt netjes de dns gewijzigd in /etc/resolv.conf door update-resolv-conf. Echter, er wordt hier alleen een DNS toegevoegd, de oude is er ook nog. Ik wil dat alleen de DNS wordt gebruikt die door OpenVPN wordt gepushed. Heeft iemand hier een mooie CLI oplossing voor? Het gaat om een Freedombox, dit gebruikt networkmanager en firewalld. Ik heb "resolvconf" geinstalleerd om update-resolv-conf werkend te krijgen, dit was niet standaard geinstalleerd. Ik vond hier wel wat informatie, maar geen bruikbare oplossing: https://wiki.archlinux.org/index.php/OpenVPN#DNS Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: openvpn
Op 06-01-19 om 12:24 schreef Fred: >> Geef eens "ip r" terwijl je VPN open is, en kijk naar de regel met >> "default". Dat is je default gateway. > Dat is dus het adres van mijn router.. Dan gaat het overige verkeer niet via de VPN. Als je echter je Pi wilt benaderen kun je een IP als 10.8.0.1 gebruiken, dat verkeer gaat wel via de VPN. Ook kun je je Pi zo configureren dat hij als router kan fungeren naar b.v. apparaten in je lokale netwerk. >> "ip -6 r" is interessant voor IPv6, als er IPv6 is gaat dat voor. Ik heb >> wel gehad dat ipv6 een andere gateway had dan IPv4. >> >> Je zult weinig last hebben van de VPN als alleen verkeer naar jouw >> apparatuur er door gaat. Maar je kunt de VPN ook default niet aanzetten >> en alleen als nodig aan, zoals boven beschreven. >> >>> Is er overigens ook nog een mogelijkheid om te testen of de vpn >>> betrouwbaar werkt..? >> Mijn ervaring is dat het betrouwbaar werkt, maar dat zul je zelf wel >> merken. Misschien begrijp ik je vraag niet helemaal goed. > Eigenlijk doelde ik op bijv. een site (whatismyipaddress) die het > gebruikte ip-adres laat zien. > Deze geeft trouwens wel het ipv6 adres terug... Nu zul je je gewone IP zien. Als je al je verkeer via de VPN wilt sturen zul je de boel iets anders moeten configureren. Maar dat kan ook. Je ziet dan het IP van de Pi, waarschijnlijk dus je IP thuis. >> Er zullen echter plekken zijn waar het niet werkt, omdat men daar de >> poort waarop OpenVPN werkt blokkeert en bijvoorbeeld alleen poort 80 en >> 443 TCP doorlaat. Sommige gastnetwerken doen dat. > Het valt mij al op dat er vanaf de laptop met de kabel al veel sites > zijn die niet weer gegeven worden. > Maar dit kan natuurlijk toeval zijn. Ik denk dat je bij dat soort sites helemaal niet werkt via de VPN, en dat het dus toeval is moet zijn. >> Verder lijkt me dat je op je Pi de poorten dichtzet, behalve die van de >> VPN. Je kunt er dus niet opkomen als de VPN niet zou werken. >> Overweeg dat niet alleen tegenover internet te doen, maar ook lokaal. > Ok, iptables oid..? Weer iets uit te zoeken ;-) Inderdaad, iptables. Al heb je tegenwoordig ook iets nieuws. Verder port-forwarding op je router naar je Pi van poort 1194 UDP. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: openvpn
Op 05-01-19 om 22:36 schreef Paul van der Vlis:
Op 05-01-19 om 20:36 schreef Fred:> Op 03-01-19 om 20:42 schreef Paul
van der Vlis:
Je zou het ook zonder de network-manager plugin kunnen doen.
Gewoon het configfile in /etc/openvpn/ zetten en renamen (.ovpn moet
.conf worden). Daarna reboot ik normaal, de VPN start dan automatisch
als er een netwerkverbinding is.
Je kunt hem echter ook uitzetten in /etc/default/openvpn en hem met de
hand starten ("openvpn --config /path/configfile".
Dit werkt inderdaad.
In tegenstelling tot de optie met de netwerkmanager moet/ga ik nu steeds
door de vpn server heen.
Wellicht is dat geen probleem, maar is hier nog een alternatief voor..?
Default gaat alleen dataverkeer naar je eigen apparatuur door de VPN en
ander internetverkeer niet. Waarom denk je dat al het verkeer door de
VPN gaat?
Vermoedelijk door een gebrek aan kennis en door de veronderstelling dat
je juist in het netwerkbeheer van Gnome de VPN uit kan zetten wanneer je
VPN niet nodig acht. Andersom ging ik er dus vanuit dat als je VPN niet
uit zet dat alle verkeer dus door de VPN gaat. Met alle verkeer bedoel
ik ook een bericht zoals deze.
Maar zoals ik al begon; ... een gebrek aan kennis.
Er zijn wel mogelijkheden dit te veranderen met het commando
"redirect-gateway" maar dat zag ik niet in je configfile.
Mijn ervaring met NetworkManagers OpenVPN-plugin is, dat het daar anders
is, dat implementeerd OpenVPN niet correct naar mijn mening! (getest met
de versie uit Debian Stable). Het default is daar dat al het verkeer via
de VPN gaat, tenzij je dit wijzigt.
Geef eens "ip r" terwijl je VPN open is, en kijk naar de regel met
"default". Dat is je default gateway.
Dat is dus het adres van mijn router..
"ip -6 r" is interessant voor IPv6, als er IPv6 is gaat dat voor. Ik heb
wel gehad dat ipv6 een andere gateway had dan IPv4.
Je zult weinig last hebben van de VPN als alleen verkeer naar jouw
apparatuur er door gaat. Maar je kunt de VPN ook default niet aanzetten
en alleen als nodig aan, zoals boven beschreven.
Is er overigens ook nog een mogelijkheid om te testen of de vpn
betrouwbaar werkt..?
Mijn ervaring is dat het betrouwbaar werkt, maar dat zul je zelf wel
merken. Misschien begrijp ik je vraag niet helemaal goed.
Eigenlijk doelde ik op bijv. een site (whatismyipaddress) die het
gebruikte ip-adres laat zien.
Deze geeft trouwens wel het ipv6 adres terug...
Er zullen echter plekken zijn waar het niet werkt, omdat men daar de
poort waarop OpenVPN werkt blokkeert en bijvoorbeeld alleen poort 80 en
443 TCP doorlaat. Sommige gastnetwerken doen dat.
Het valt mij al op dat er vanaf de laptop met de kabel al veel sites
zijn die niet weer gegeven worden.
Maar dit kan natuurlijk toeval zijn.
Verder lijkt me dat je op je Pi de poorten dichtzet, behalve die van de
VPN. Je kunt er dus niet opkomen als de VPN niet zou werken.
Overweeg dat niet alleen tegenover internet te doen, maar ook lokaal.
Ok, iptables oid..? Weer iets uit te zoeken ;-)
Gr Fred
Re: openvpn
Op 05-01-19 om 20:36 schreef Fred:> Op 03-01-19 om 20:42 schreef Paul
van der Vlis:
>> Je zou het ook zonder de network-manager plugin kunnen doen.
>> Gewoon het configfile in /etc/openvpn/ zetten en renamen (.ovpn moet
>> .conf worden). Daarna reboot ik normaal, de VPN start dan automatisch
>> als er een netwerkverbinding is.
>>
>> Je kunt hem echter ook uitzetten in /etc/default/openvpn en hem met de
>> hand starten ("openvpn --config /path/configfile".
> Dit werkt inderdaad.
> In tegenstelling tot de optie met de netwerkmanager moet/ga ik nu steeds
> door de vpn server heen.
> Wellicht is dat geen probleem, maar is hier nog een alternatief voor..?
Default gaat alleen dataverkeer naar je eigen apparatuur door de VPN en
ander internetverkeer niet. Waarom denk je dat al het verkeer door de
VPN gaat?
Er zijn wel mogelijkheden dit te veranderen met het commando
"redirect-gateway" maar dat zag ik niet in je configfile.
Mijn ervaring met NetworkManagers OpenVPN-plugin is, dat het daar anders
is, dat implementeerd OpenVPN niet correct naar mijn mening! (getest met
de versie uit Debian Stable). Het default is daar dat al het verkeer via
de VPN gaat, tenzij je dit wijzigt.
Geef eens "ip r" terwijl je VPN open is, en kijk naar de regel met
"default". Dat is je default gateway.
"ip -6 r" is interessant voor IPv6, als er IPv6 is gaat dat voor. Ik heb
wel gehad dat ipv6 een andere gateway had dan IPv4.
Je zult weinig last hebben van de VPN als alleen verkeer naar jouw
apparatuur er door gaat. Maar je kunt de VPN ook default niet aanzetten
en alleen als nodig aan, zoals boven beschreven.
> Is er overigens ook nog een mogelijkheid om te testen of de vpn
> betrouwbaar werkt..?
Mijn ervaring is dat het betrouwbaar werkt, maar dat zul je zelf wel
merken. Misschien begrijp ik je vraag niet helemaal goed.
Er zullen echter plekken zijn waar het niet werkt, omdat men daar de
poort waarop OpenVPN werkt blokkeert en bijvoorbeeld alleen poort 80 en
443 TCP doorlaat. Sommige gastnetwerken doen dat.
Verder lijkt me dat je op je Pi de poorten dichtzet, behalve die van de
VPN. Je kunt er dus niet opkomen als de VPN niet zou werken.
Overweeg dat niet alleen tegenover internet te doen, maar ook lokaal.
Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Re: openvpn
Op 03-01-19 om 20:42 schreef Paul van der Vlis:
Op 03-01-19 om 19:45 schreef Fred:
Op 03-01-19 om 19:01 schreef Paul van der Vlis:
Op 03-01-19 om 17:45 schreef Fred:
Op 03-01-19 om 17:39 schreef Paul van der Vlis:
Op 03-01-19 om 15:05 schreef Fred:
Op 02-01-19 om 20:53 schreef Paul van der Vlis:
Hoi,
Op 02-01-19 om 20:00 schreef Fred:
Beste,
Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van
mijn mobiel een verbinding kan krijgen.
Vanaf mijn laptop lukt dit echter niet.
Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder
van
Gnome geïmporteerd echter met uitzondering van het
gedeelte.
Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil
toevoegen.
Bedoel je wellicht het gedeelte?
Als je dat op de server hebt, moet je het ook op de client hebben.
Je kunt het dus ook weghalen aan zowel de server als de client kant.
Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd;
#
#
# 2048 bit OpenVPN static key
#
#-BEGIN OpenVPN Static key V1-
Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de
regels van n comment out # heb voorzien wel.
Het gaat volgens mij dus wel om i,p,v (?)
Maar in jou methode om een .opvn bestand te genereren zie ik juist die
tag niet terug.
Wellicht dat dat juist het probleem is. De log verwijst in elk
geval wel
naar een tls issue.
Ik zie dus zoiets en dat werkt:
#
# 2048 bit OpenVPN static key
#
-BEGIN OpenVPN Static key V1-
(...)
-END OpenVPN Static key V1-
Probeer het misschien eens aan te passen.
Dat heb ik juist geprobeerd maar levert ook niet het gewenste
resultaat op;
De log laat dan dit zien;
Jan 3 15:37:00 raspberrypi ovpn-server[338]: tls-crypt unwrap error:
packet authentication failed
Jan 3 15:37:00 raspberrypi ovpn-server[338]: TLS Error: tls-crypt
unwrapping failed from [AF_INET]
Ik heb nog wat verder gekeken, tls-auth is wat anders dan tls-crypt. Als
ik me niet vergis is tls-crypt nieuwer/beter, maar het zou best eens
kunnen dat networkmanager in Debian het nog niet ondersteund.
Hmm, ik zie dat er ook een backports-versie van is.
Uit de manual: "In contrast to --tls-auth, --tls-crypt does *not*
require the user to set --key-direction."
Met tls-crypt heb ik nog geen ervaring. Hieronder ga ik in op tls-auth.
Networkmanager importeert alles nu netjes?
Ja, als ik van maak dan wordt het ovpn config
bestand wel geïmporteerd, maar wel geeft dus toch in de log van de
server een foutmelding zoals hierboven. Het bestand word ook
geïmporteerd als ik de regels out comment.
Wat staat er op de tls-auth regel in je client-configfile?
Bij mij staat er dit:
tls-auth ta.key 1
Die komt in mijn client-configfile niet voor.
-
client
dev tun
proto udp
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
tls-version-min 1.2
verify-x509-name server_KLsSwJCOaYqwbKIp name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
---
En hierna de certificaten en keys...
Ik heb op de client dit, daarna de certificaten en keys:
---
client
dev tun
proto udp
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3
-
Volgens mij verschilt de cipher en heb jij "auth" waar ik "tls-auth"
heb, en dan de "direction".
Dit staat er bij mij in het server configfile:
tls-auth /etc/openvpn/keys/ta.key 0
Let op die laatste 0 en 1, dat is de direction.
Bij mij;
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
Dus zonder toevoeging van 0 of 1
Bovenstaande regel lijkt me geschikt voor tls-crypt en niet voor tls-auth.
Je zult moeten kiezen tussen tls-auth en tls-crypt.
Met dat laatste heb ik nog geen ervaring.
En of de network-manager openvpn plugin daarmee werkt weet ik niet.
Je zou het ook eerst zonder tls-crypt of tls-auth aan de praat kunnen
brengen om te zien of het dan werkt.
Je zou het ook zonder de network-manager plugin kunnen doen.
Gewoon het configfile in /etc/openvpn/ zetten en renamen (.ovpn moet
.conf worden). Daarna reboot ik normaal, de VPN start dan automatisch
als er een netwerkverbinding is.
Je kunt hem echter ook uitzetten in /etc/default/openvpn en hem met de
hand starten ("openvpn --config /path/configfile".
Dit werkt inderdaad.
In tegenstelling tot de optie met de netwerkmanager moet/ga ik nu steeds
door de vpn server heen.
Wellicht is dat geen probleem, maar is hier nog een alternatief voor..?
Is er overigens ook nog een mogelijkheid om te testen of de vpn
betrouwbaar werkt..?
Gr Fred
Re: openvpn
Op 03-01-19 om 19:45 schreef Fred:
>
>
> Op 03-01-19 om 19:01 schreef Paul van der Vlis:
>> Op 03-01-19 om 17:45 schreef Fred:
>>>
>>> Op 03-01-19 om 17:39 schreef Paul van der Vlis:
>>>> Op 03-01-19 om 15:05 schreef Fred:
>>>>> Op 02-01-19 om 20:53 schreef Paul van der Vlis:
>>>>>> Hoi,
>>>>>>
>>>>>> Op 02-01-19 om 20:00 schreef Fred:
>>>>>>> Beste,
>>>>>>>
>>>>>>> Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van
>>>>>>> mijn mobiel een verbinding kan krijgen.
>>>>>>> Vanaf mijn laptop lukt dit echter niet.
>>>>>>>
>>>>>>> Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder
>>>>>>> van
>>>>>>> Gnome geïmporteerd echter met uitzondering van het
>>>>>>> gedeelte.
>>>>>>> Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil
>>>>>>> toevoegen.
>>>>>> Bedoel je wellicht het gedeelte?
>>>>>> Als je dat op de server hebt, moet je het ook op de client hebben.
>>>>>> Je kunt het dus ook weghalen aan zowel de server als de client kant.
>>>>> Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd;
>>>>>
>>>>>> #
>>>>>> #
>>>>>> # 2048 bit OpenVPN static key
>>>>>> #
>>>>>> #-BEGIN OpenVPN Static key V1-
>>>>> Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de
>>>>> regels van n comment out # heb voorzien wel.
>>>>> Het gaat volgens mij dus wel om i,p,v (?)
>>>>>
>>>>> Maar in jou methode om een .opvn bestand te genereren zie ik juist die
>>>>> tag niet terug.
>>>>> Wellicht dat dat juist het probleem is. De log verwijst in elk
>>>>> geval wel
>>>>> naar een tls issue.
>>>> Ik zie dus zoiets en dat werkt:
>>>>
>>>>
>>>> #
>>>> # 2048 bit OpenVPN static key
>>>> #
>>>> -BEGIN OpenVPN Static key V1-
>>>>
>>>> (...)
>>>>
>>>> -END OpenVPN Static key V1-
>>>>
>>>>
>>>>
>>>> Probeer het misschien eens aan te passen.
>>> Dat heb ik juist geprobeerd maar levert ook niet het gewenste
>>> resultaat op;
>>> De log laat dan dit zien;
>>> Jan 3 15:37:00 raspberrypi ovpn-server[338]: tls-crypt unwrap error:
>>> packet authentication failed
>>> Jan 3 15:37:00 raspberrypi ovpn-server[338]: TLS Error: tls-crypt
>>> unwrapping failed from [AF_INET]
>> Ik heb nog wat verder gekeken, tls-auth is wat anders dan tls-crypt. Als
>> ik me niet vergis is tls-crypt nieuwer/beter, maar het zou best eens
>> kunnen dat networkmanager in Debian het nog niet ondersteund.
>> Hmm, ik zie dat er ook een backports-versie van is.
>>
>> Uit de manual: "In contrast to --tls-auth, --tls-crypt does *not*
>> require the user to set --key-direction."
>>
>> Met tls-crypt heb ik nog geen ervaring. Hieronder ga ik in op tls-auth.
>>
>> Networkmanager importeert alles nu netjes?
> Ja, als ik van maak dan wordt het ovpn config
> bestand wel geïmporteerd, maar wel geeft dus toch in de log van de
> server een foutmelding zoals hierboven. Het bestand word ook
> geïmporteerd als ik de regels out comment.
>>
>> Wat staat er op de tls-auth regel in je client-configfile?
>> Bij mij staat er dit:
>> tls-auth ta.key 1
> Die komt in mijn client-configfile niet voor.
>
> -
> client
> dev tun
> proto udp
> remote xx.xx.xx.xx 1194
> resolv-retry infinite
> nobind
> persist-key
> persist-tun
> remote-cert-tls server
> tls-version-min 1.2
> verify-x509-name server_KLsSwJCOaYqwbKIp name
> cipher AES-256-CBC
> auth SHA256
> auth-nocache
> verb 3
> ---
> En hierna de certificaten en keys...
Ik heb op de client dit, daarna de certificaten en keys:
---
client
dev tun
proto udp
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3
-
Volgens mij verschilt de cipher en heb jij "auth" waar ik "tls-auth"
heb, en dan de "direction".
>> Dit staat er bij mij in het server configfile:
>> tls-auth /etc/openvpn/keys/ta.key 0
>> Let op die laatste 0 en 1, dat is de direction.
> Bij mij;
> tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
>
> Dus zonder toevoeging van 0 of 1
Bovenstaande regel lijkt me geschikt voor tls-crypt en niet voor tls-auth.
Je zult moeten kiezen tussen tls-auth en tls-crypt.
Met dat laatste heb ik nog geen ervaring.
En of de network-manager openvpn plugin daarmee werkt weet ik niet.
Je zou het ook eerst zonder tls-crypt of tls-auth aan de praat kunnen
brengen om te zien of het dan werkt.
Je zou het ook zonder de network-manager plugin kunnen doen.
Gewoon het configfile in /etc/openvpn/ zetten en renamen (.ovpn moet
.conf worden). Daarna reboot ik normaal, de VPN start dan automatisch
als er een netwerkverbinding is.
Je kunt hem echter ook uitzetten in /etc/default/openvpn en hem met de
hand starten ("openvpn --config /path/configfile".
Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Re: openvpn
Op 03-01-19 om 19:01 schreef Paul van der Vlis: Op 03-01-19 om 17:45 schreef Fred: Op 03-01-19 om 17:39 schreef Paul van der Vlis: Op 03-01-19 om 15:05 schreef Fred: Op 02-01-19 om 20:53 schreef Paul van der Vlis: Hoi, Op 02-01-19 om 20:00 schreef Fred: Beste, Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van mijn mobiel een verbinding kan krijgen. Vanaf mijn laptop lukt dit echter niet. Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van Gnome geïmporteerd echter met uitzondering van het gedeelte. Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil toevoegen. Bedoel je wellicht het gedeelte? Als je dat op de server hebt, moet je het ook op de client hebben. Je kunt het dus ook weghalen aan zowel de server als de client kant. Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd; # # # 2048 bit OpenVPN static key # #-BEGIN OpenVPN Static key V1- Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de regels van n comment out # heb voorzien wel. Het gaat volgens mij dus wel om i,p,v (?) Maar in jou methode om een .opvn bestand te genereren zie ik juist die tag niet terug. Wellicht dat dat juist het probleem is. De log verwijst in elk geval wel naar een tls issue. Ik zie dus zoiets en dat werkt: # # 2048 bit OpenVPN static key # -BEGIN OpenVPN Static key V1- (...) -END OpenVPN Static key V1- Probeer het misschien eens aan te passen. Dat heb ik juist geprobeerd maar levert ook niet het gewenste resultaat op; De log laat dan dit zien; Jan 3 15:37:00 raspberrypi ovpn-server[338]: tls-crypt unwrap error: packet authentication failed Jan 3 15:37:00 raspberrypi ovpn-server[338]: TLS Error: tls-crypt unwrapping failed from [AF_INET] Ik heb nog wat verder gekeken, tls-auth is wat anders dan tls-crypt. Als ik me niet vergis is tls-crypt nieuwer/beter, maar het zou best eens kunnen dat networkmanager in Debian het nog niet ondersteund. Hmm, ik zie dat er ook een backports-versie van is. Uit de manual: "In contrast to --tls-auth, --tls-crypt does *not* require the user to set --key-direction." Met tls-crypt heb ik nog geen ervaring. Hieronder ga ik in op tls-auth. Networkmanager importeert alles nu netjes? Ja, als ik van maak dan wordt het ovpn config bestand wel geïmporteerd, maar wel geeft dus toch in de log van de server een foutmelding zoals hierboven. Het bestand word ook geïmporteerd als ik de regels out comment. Wat staat er op de tls-auth regel in je client-configfile? Bij mij staat er dit: tls-auth ta.key 1 Die komt in mijn client-configfile niet voor. - client dev tun proto udp remote xx.xx.xx.xx 1194 resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server tls-version-min 1.2 verify-x509-name server_KLsSwJCOaYqwbKIp name cipher AES-256-CBC auth SHA256 auth-nocache verb 3 --- En hierna de certificaten en keys... Dit staat er bij mij in het server configfile: tls-auth /etc/openvpn/keys/ta.key 0 Let op die laatste 0 en 1, dat is de direction. Bij mij; tls-crypt /etc/openvpn/easy-rsa/pki/ta.key Dus zonder toevoeging van 0 of 1 gr Fred
Re: openvpn
Op 03-01-19 om 17:45 schreef Fred: > > > Op 03-01-19 om 17:39 schreef Paul van der Vlis: >> Op 03-01-19 om 15:05 schreef Fred: >>> >>> Op 02-01-19 om 20:53 schreef Paul van der Vlis: >>>> Hoi, >>>> >>>> Op 02-01-19 om 20:00 schreef Fred: >>>>> Beste, >>>>> >>>>> Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van >>>>> mijn mobiel een verbinding kan krijgen. >>>>> Vanaf mijn laptop lukt dit echter niet. >>>>> >>>>> Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van >>>>> Gnome geïmporteerd echter met uitzondering van het >>>>> gedeelte. >>>>> Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil >>>>> toevoegen. >>>> Bedoel je wellicht het gedeelte? >>>> Als je dat op de server hebt, moet je het ook op de client hebben. >>>> Je kunt het dus ook weghalen aan zowel de server als de client kant. >>> Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd; >>> >>>> # >>>> # >>>> # 2048 bit OpenVPN static key >>>> # >>>> #-BEGIN OpenVPN Static key V1- >>> Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de >>> regels van n comment out # heb voorzien wel. >>> Het gaat volgens mij dus wel om i,p,v (?) >>> >>> Maar in jou methode om een .opvn bestand te genereren zie ik juist die >>> tag niet terug. >>> Wellicht dat dat juist het probleem is. De log verwijst in elk geval wel >>> naar een tls issue. >> Ik zie dus zoiets en dat werkt: >> >> >> # >> # 2048 bit OpenVPN static key >> # >> -BEGIN OpenVPN Static key V1- >> >> (...) >> >> -END OpenVPN Static key V1- >> >> >> >> Probeer het misschien eens aan te passen. > Dat heb ik juist geprobeerd maar levert ook niet het gewenste resultaat op; > De log laat dan dit zien; > Jan 3 15:37:00 raspberrypi ovpn-server[338]: tls-crypt unwrap error: > packet authentication failed > Jan 3 15:37:00 raspberrypi ovpn-server[338]: TLS Error: tls-crypt > unwrapping failed from [AF_INET] Ik heb nog wat verder gekeken, tls-auth is wat anders dan tls-crypt. Als ik me niet vergis is tls-crypt nieuwer/beter, maar het zou best eens kunnen dat networkmanager in Debian het nog niet ondersteund. Hmm, ik zie dat er ook een backports-versie van is. Uit de manual: "In contrast to --tls-auth, --tls-crypt does *not* require the user to set --key-direction." Met tls-crypt heb ik nog geen ervaring. Hieronder ga ik in op tls-auth. Networkmanager importeert alles nu netjes? Wat staat er op de tls-auth regel in je client-configfile? Bij mij staat er dit: tls-auth ta.key 1 Dit staat er bij mij in het server configfile: tls-auth /etc/openvpn/keys/ta.key 0 Let op die laatste 0 en 1, dat is de direction. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: openvpn
Op 03-01-19 om 17:39 schreef Paul van der Vlis: Op 03-01-19 om 15:05 schreef Fred: Op 02-01-19 om 20:53 schreef Paul van der Vlis: Hoi, Op 02-01-19 om 20:00 schreef Fred: Beste, Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van mijn mobiel een verbinding kan krijgen. Vanaf mijn laptop lukt dit echter niet. Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van Gnome geïmporteerd echter met uitzondering van het gedeelte. Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil toevoegen. Bedoel je wellicht het gedeelte? Als je dat op de server hebt, moet je het ook op de client hebben. Je kunt het dus ook weghalen aan zowel de server als de client kant. Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd; # # # 2048 bit OpenVPN static key # #-BEGIN OpenVPN Static key V1- Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de regels van n comment out # heb voorzien wel. Het gaat volgens mij dus wel om i,p,v (?) Maar in jou methode om een .opvn bestand te genereren zie ik juist die tag niet terug. Wellicht dat dat juist het probleem is. De log verwijst in elk geval wel naar een tls issue. Ik zie dus zoiets en dat werkt: # # 2048 bit OpenVPN static key # -BEGIN OpenVPN Static key V1- (...) -END OpenVPN Static key V1- Probeer het misschien eens aan te passen. Dat heb ik juist geprobeerd maar levert ook niet het gewenste resultaat op; De log laat dan dit zien; Jan 3 15:37:00 raspberrypi ovpn-server[338]: tls-crypt unwrap error: packet authentication failed Jan 3 15:37:00 raspberrypi ovpn-server[338]: TLS Error: tls-crypt unwrapping failed from [AF_INET] gr Fred
Re: openvpn
Op 03-01-19 om 15:05 schreef Fred: > > > Op 02-01-19 om 20:53 schreef Paul van der Vlis: >> Hoi, >> >> Op 02-01-19 om 20:00 schreef Fred: >>> Beste, >>> >>> Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van >>> mijn mobiel een verbinding kan krijgen. >>> Vanaf mijn laptop lukt dit echter niet. >>> >>> Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van >>> Gnome geïmporteerd echter met uitzondering van het gedeelte. >>> Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil >>> toevoegen. >> Bedoel je wellicht het gedeelte? >> Als je dat op de server hebt, moet je het ook op de client hebben. >> Je kunt het dus ook weghalen aan zowel de server als de client kant. > Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd; > >> # >> # >> # 2048 bit OpenVPN static key >> # >> #-BEGIN OpenVPN Static key V1- > Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de > regels van n comment out # heb voorzien wel. > Het gaat volgens mij dus wel om i,p,v (?) > > Maar in jou methode om een .opvn bestand te genereren zie ik juist die > tag niet terug. > Wellicht dat dat juist het probleem is. De log verwijst in elk geval wel > naar een tls issue. Ik zie dus zoiets en dat werkt: # # 2048 bit OpenVPN static key # -BEGIN OpenVPN Static key V1- (...) -END OpenVPN Static key V1- Probeer het misschien eens aan te passen. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: openvpn
Op 02-01-19 om 20:53 schreef Paul van der Vlis: Hoi, Op 02-01-19 om 20:00 schreef Fred: Beste, Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van mijn mobiel een verbinding kan krijgen. Vanaf mijn laptop lukt dit echter niet. Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van Gnome geïmporteerd echter met uitzondering van het gedeelte. Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil toevoegen. Bedoel je wellicht het gedeelte? Als je dat op de server hebt, moet je het ook op de client hebben. Je kunt het dus ook weghalen aan zowel de server als de client kant. Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd; # # # 2048 bit OpenVPN static key # #-BEGIN OpenVPN Static key V1- Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de regels van n comment out # heb voorzien wel. Het gaat volgens mij dus wel om i,p,v (?) Maar in jou methode om een .opvn bestand te genereren zie ik juist die tag niet terug. Wellicht dat dat juist het probleem is. De log verwijst in elk geval wel naar een tls issue. Gr Fred
Re: openvpn
Jan 2 20:25:07 raspberrypi ovpn-server[338]: tls-crypt unwrap error: packet too short Jan 2 20:25:07 raspberrypi ovpn-server[338]: TLS Error: tls-crypt unwrapping failed from [AF_INET] Fred Op 02-01-19 om 20:58 schreef Geert Stappers: On Wed, Jan 02, 2019 at 08:00:14PM +0100, Fred wrote: Beste, Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van mijn mobiel een verbinding kan krijgen. Vanaf mijn laptop lukt dit echter niet. Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van Gnome geïmporteerd echter met uitzondering van het gedeelte. Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil toevoegen. het .ovpn bestand word zo door het netwerkbeheer wel geaccepteerd maar er word geen verbinding gemaakt. Ik heb geen idee waar ik nu verder kan/moet zoeken om te kunnen achterhalen wat er mis gaat. Wat komt er in logging van de server in kwestie? Groeten Geert Stappers
Re: openvpn
Hoi, Op 02-01-19 om 20:00 schreef Fred: > Beste, > > Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van > mijn mobiel een verbinding kan krijgen. > Vanaf mijn laptop lukt dit echter niet. > > Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van > Gnome geïmporteerd echter met uitzondering van het gedeelte. > Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil toevoegen. Bedoel je wellicht het gedeelte? Als je dat op de server hebt, moet je het ook op de client hebben. Je kunt het dus ook weghalen aan zowel de server als de client kant. Bij mij werkt het met een .ovpn file in network-manager, maar ik gebruik het niet meer. Vooral omdat network-manager rare dingen doet met de DNS. Dat is wel te wijzigen, maar dat vind ik lastig. Ik werk nu direct met openvpn. Je moet het .ovpn file renamen naar .conf, maar dan werkt het meteen. En de DNS is dan ook te configureren via het configfile. > het .ovpn bestand word zo door het netwerkbeheer wel geaccepteerd maar > er word geen verbinding gemaakt.> Ik heb geen idee waar ik nu verder kan/moet > zoeken om te kunnen > achterhalen wat er mis gaat. > > iemand..? Mijn rare ervaring met openvpn: reboot de machine. Daarna komt er pas van alles in /var/log/syslog en dat kan je verder helpen. Misschien heb je hier nog iets aan, hoe ik een .ovpn-file maak: -- cd /etc/openvpn/easy-rsa/keys/ cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ./ pas in client.conf de servername aan (zoek op "remote") naam=vpn #naam is belangrijk, want zie je in network-manager cp -a client.conf $naam.ovpn echo "" >> $naam.ovpn echo "" >> $naam.ovpn cat ca.crt >> $naam.ovpn echo "" >> $naam.ovpn echo "" >> $naam.ovpn cat $naam.crt >> $naam.ovpn echo "" >> $naam.ovpn echo "" >> $naam.ovpn cat $naam.key >> $naam.ovpn echo "" >> $naam.ovpn echo "" >> $naam.ovpn cat ta.key >> $naam.ovpn echo "" >> $naam.ovpn -- Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: openvpn
On Wed, Jan 02, 2019 at 08:00:14PM +0100, Fred wrote: > Beste, > > Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van mijn > mobiel een verbinding kan krijgen. > Vanaf mijn laptop lukt dit echter niet. > > Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van Gnome > geïmporteerd echter met uitzondering van het gedeelte. > Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil toevoegen. > > het .ovpn bestand word zo door het netwerkbeheer wel geaccepteerd maar er > word geen verbinding gemaakt. > Ik heb geen idee waar ik nu verder kan/moet zoeken om te kunnen achterhalen > wat er mis gaat. Wat komt er in logging van de server in kwestie? Groeten Geert Stappers -- Leven en laten leven
openvpn
Beste, Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van mijn mobiel een verbinding kan krijgen. Vanaf mijn laptop lukt dit echter niet. Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van Gnome geïmporteerd echter met uitzondering van het gedeelte. Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil toevoegen. het .ovpn bestand word zo door het netwerkbeheer wel geaccepteerd maar er word geen verbinding gemaakt. Ik heb geen idee waar ik nu verder kan/moet zoeken om te kunnen achterhalen wat er mis gaat. iemand..? Fred
Re: Samba via OpenVPN
Op 27-01-18 om 16:10 schreef Paul van der Vlis: > Op 26-01-18 om 23:04 schreef Paul van der Vlis: >> Op 26-01-18 om 21:42 schreef Paul van der Vlis: >> >>> Ik ga kijken wat de beste MTU is, en of ik die ook server-side kan >>> instellen. Mijn tests nu zijn client-side. >> >> Ik heb de MTU aan de server-kant op 1000 gezet door in >> /etc/default/openvpn "OPTARGS="--tun-mtu 1000" te zetten, en dit lijkt >> te helpen. >> >> Als ik ifconfig uitvoer op de server, dan zie ik bij het TUN-device een >> MTU van 1000. Op de client van 1500. > > Jammer genoeg lijkt dit vanaf een Windows client niet te werken. > Er komt geen connectie tot stand zegt men. > >> Aan de client-kant had ik in network-manager ook succes met de optie >> "Maximale TCP-segmentgrote (MSS) van de tunnel beperken". >> Aan de server-kant hielp de optie --mssfix (zonder parameter) niet. > Ik heb er nu "--mssfix 1000" neergezet. Dit werkt vanaf Linux, of het > vanaf Windows werkt wacht ik nog af. Hiermee werkt het weer. Wellicht valt er nog wat te fine-tunen. Wat me opviel was dat na het aanpassen van --tun-mtu ik geen grote pakketten kon pingen via de VPN. Dat kan nu met die --mssfix wel. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Samba via OpenVPN
Op 26-01-18 om 23:04 schreef Paul van der Vlis: > Op 26-01-18 om 21:42 schreef Paul van der Vlis: > >> Ik ga kijken wat de beste MTU is, en of ik die ook server-side kan >> instellen. Mijn tests nu zijn client-side. > > Ik heb de MTU aan de server-kant op 1000 gezet door in > /etc/default/openvpn "OPTARGS="--tun-mtu 1000" te zetten, en dit lijkt > te helpen. > > Als ik ifconfig uitvoer op de server, dan zie ik bij het TUN-device een > MTU van 1000. Op de client van 1500. Jammer genoeg lijkt dit vanaf een Windows client niet te werken. Er komt geen connectie tot stand zegt men. > Aan de client-kant had ik in network-manager ook succes met de optie > "Maximale TCP-segmentgrote (MSS) van de tunnel beperken". > Aan de server-kant hielp de optie --mssfix (zonder parameter) niet. Ik heb er nu "--mssfix 1000" neergezet. Dit werkt vanaf Linux, of het vanaf Windows werkt wacht ik nog af. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Samba via OpenVPN
Op 26-01-18 om 21:42 schreef Paul van der Vlis: > Ik ga kijken wat de beste MTU is, en of ik die ook server-side kan > instellen. Mijn tests nu zijn client-side. Ik heb de MTU aan de server-kant op 1000 gezet door in /etc/default/openvpn "OPTARGS="--tun-mtu 1000" te zetten, en dit lijkt te helpen. Als ik ifconfig uitvoer op de server, dan zie ik bij het TUN-device een MTU van 1000. Op de client van 1500. Aan de client-kant had ik in network-manager ook succes met de optie "Maximale TCP-segmentgrote (MSS) van de tunnel beperken". Aan de server-kant hielp de optie --mssfix (zonder parameter) niet. Jammer genoeg is de boel daar niet te pingen. Via ping kun je de optimale MTU uitvinden zo lees ik. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Samba via OpenVPN
Op 26-01-18 om 20:24 schreef Paul van der Vlis: > Op 26-01-18 om 15:15 schreef Rik Theys: >> Hoi, >> >> Wilde gok maar ik zou eens proberen om de mtu te verkleinen. > > MTU verkleinen helpt niet. Hmm, ik heb hem nog verder verkleind (naar 1000), en nu helpt het wel... Het gaat niet echt snel, maar het werkt wel. Ik ga kijken wat de beste MTU is, en of ik die ook server-side kan instellen. Mijn tests nu zijn client-side. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Samba via OpenVPN
Op 26-01-18 om 15:15 schreef Rik Theys: > Hoi, > > Wilde gok maar ik zou eens proberen om de mtu te verkleinen. MTU verkleinen helpt niet. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Samba via OpenVPN
Hoi, Wilde gok maar ik zou eens proberen om de mtu te verkleinen. Rik Op 26 jan. 2018 2:02 p.m. schreef "Paul van der Vlis" <p...@vandervlis.nl>: Hoi, Bij een klant staat al jaren een Samba server, op het moment gebruiken ze Debian7 met Samba 4.1.17 (uit Wheezy-backports). Dus een oud systeem. Ze gebruiken dit ook vanuit huis via OpenVPN. Op kantoor daar werkt alles goed, maar via OpenVPN is er plots een probleem. Je ziet de bestanden, maar als je er op klikt werkt het heel traag, veelal komt er een timeout (maar soms niet). Ik kan dit ook vanuit hier reproduceren onder Linux. Iemand een idee wat dit kan zijn? Volgens mij werkt OpenVPN goed en moet het dus ergens in Samba of de combinatie zitten. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Samba via OpenVPN
Hoi, Bij een klant staat al jaren een Samba server, op het moment gebruiken ze Debian7 met Samba 4.1.17 (uit Wheezy-backports). Dus een oud systeem. Ze gebruiken dit ook vanuit huis via OpenVPN. Op kantoor daar werkt alles goed, maar via OpenVPN is er plots een probleem. Je ziet de bestanden, maar als je er op klikt werkt het heel traag, veelal komt er een timeout (maar soms niet). Ik kan dit ook vanuit hier reproduceren onder Linux. Iemand een idee wat dit kan zijn? Volgens mij werkt OpenVPN goed en moet het dus ergens in Samba of de combinatie zitten. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
iets met IPv6 (was: ik ben draad kwijt: wie doet wat: openvpn, systemd, network-manager-openvpn)
Wat het precies is, dat is me nog onduidelijk. Maar het 'probleem' doet zich voor op LAN met IPv6 ondersteuning, denk ik. Daar werkt Openvpn wel , maar nm-openvpn niet. In cafe's en dergelijke met IPv4 draait nm-openvpn als vanouds, zolan Openvpn maar niet draait.
ik ben draad kwijt: wie doet wat: openvpn, systemd, network-manager-openvpn
Since dinsdag of woensdag (vermoed ik) is er in Debian Unstable iets veranderd, waarna mijn openvpn zich anders opzet dan ik gewend ben. Maar misschien herinner ik me zaken verkeerd. Ik heb een setje instellingen in een bestandje "laptop.conf" en dat staat in /etc/openvpn/ Ergens lang geleden wees ik network-manager 1 keer naar dat bestandje (import a saved vpn configuration). Sinsddien zette ik "laptop" als VPN handmatig op voor iedere WIFI-verbinding, op kantoor, in de trein, in hotels etcetera. Gisterenochtend (?) in een anders' kantoor, ontdekte ik dat die methode niet meer werkt. Maar openvpn wordt nu (ineens?) gestart door ,eh, systemd(?) en dat zet de verbinding zelf op. In de trein, die dag, moest ik het diverse keren met de hand via network-manager aanzetten (omdat ik vijf verschillende treinen nam, lange reis), maar eenmaal thuis was het weer systemd die het deed. Begrijp het niet. Nu net getest: systemd openvnp stop openvpn met de hand starten via network-manager: lukt niet. laptop.conf weggehaald uit /etc/openvpn, laptop opnieuw opgestart. systemd laat zien dat openvpn "gestart" is, maar er is geen configuratie, dus er is niets. laptop.conf ingeladen in network-manager (import). Verbinding opzetten lukt niet. Het is een time-out, dezelfde die ik al eerder zag. TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) In de logs zie ik twee processen die met openvpn te maken hebben ovpn-laptop : dat zet op dit moment een werkende tunnel op Initialization Sequence Completed het andere process is: nm-openvpn Dat is een onderdeel van network-manager, en dat geeft als ik het aanzet, time-outs (want er draait al een tunnel/of openvpn draait zonder configuratie, of...) Misschien maak ik me druk om niets: als de VPN blijft werken is het natuurlijk ok. Wat ik raar vind is dat ik het gisteren in de trein (Wifi in de trein) wel met de hand aanzetten kon. Ik zal me zometeen eens verhuizen naar een ander netwerk, kijken wat daar gebeurt. Iemand een idee waar ik zoeken moet?
OpenVPN Opgelost
Beste , - - - - - - - - -- Doorgestuurd bericht -- Van: mourik jan c heupink <heup...@merit.unu.edu> Datum: 4 januari 2016 18:04 Onderwerp: Re: OpenVPN Aan: debian-user-dutch@lists.debian.org Hoi René, Volgens mij maak je in principe geen denktfout. Check eens met http://ip4.me of je ip adres in de vpn inderdaad het verwachte (belgische) ip adres is. - - - - - - - Het probleem lijkt te zitten in: de DNS Address detection waardoor de uiteindelijke afkomst ( Nederland ) toch zichtbaar is. De oplossing is een VPN tunnel zonder leakage. - - - - - - - - En anders blokkeren ze wellicht specifieke ip adressen. (om te voorkomen wat jij nu wil down) MJ - - - - - - - - - - Aangezien het een eenmalig probleem is is voor een andere oplossing gekozen om betreffende aflevering te bekijken. Groeten en iedereen bedankt. René.
OpenVPN
Beste .., Omdat: http://www.tvgemist.be weigert om aan "buitenlanders" ( = IP-adres buiten België ) afleveringen van een serie te tonen: http://www.tvgemist.be/canvas/jordskott/kinderen-van-silverhojd-10-10-14653 hoopte ik door OpenVPN te installeren: https://support.goldenfrog.com/hc/nl/articles/203815626-OpenVPN en daarbij voor een Belgische server te kiezen me als Belg voor te kunnen doen. Helaas werkt dit niet. Wat is mijn denkfout ? Wat zou een wel werkende oplossing kunnen zijn? Bij voorbaat dank voor het meedenken. Groeten, René. P.s.: Ubuntu 14.04 LTS
Re: OpenVPN
Hoi René, Volgens mij maak je in principe geen denktfout. Check eens met http://ip4.me of je ip adres in de vpn inderdaad het verwachte (belgische) ip adres is. En anders blokkeren ze wellicht specifieke ip adressen. (om te voorkomen wat jij nu wil down) MJ On 4-1-2016 11:59, plaater wrote: Beste .., Omdat: http://www.tvgemist.be weigert om aan "buitenlanders" ( = IP-adres buiten België ) afleveringen van een serie te tonen: http://www.tvgemist.be/canvas/jordskott/kinderen-van-silverhojd-10-10-14653 hoopte ik door OpenVPN te installeren: https://support.goldenfrog.com/hc/nl/articles/203815626-OpenVPN en daarbij voor een Belgische server te kiezen me als Belg voor te kunnen doen. Helaas werkt dit niet. Wat is mijn denkfout ? Wat zou een wel werkende oplossing kunnen zijn? Bij voorbaat dank voor het meedenken. Groeten, René. P.s.: Ubuntu 14.04 LTS
Re: shorewall, shorewall6 & openvpn
On Fri, Oct 23, 2015 at 11:36:31AM +0200, Gijs Hillenius wrote:
>
> Ik probeer shorewall & shorewall6 te combineren met openvp. Dat laatste
> werkt (denk ik), alleen zitten de twee shorewalls in de weg.
>
> Gewenste situatie: openvpn server moet het verkeer van de "road warrior
> laptop" verder leiden, het Internet op..
[ ... ]
> De meest-veelbelovende hint in de logs lijkt te wezen dat ipv6 forwarding
} disabled is.
[ ... ]
> | Starting Shorewall6
> | Initializing...
> | Preparing ip6tables-restore input...
> | Running /sbin/ip6tables-restore...
> | IPv6 Forwarding Disabled!
> `
>
> Op dit punt raak ik de weg kwijt - het woud is reusachtig, welke boom
> moet ik hebben?
>
>
> Doe ik
>
> echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
>
> dan gaat een deel van het ipv6 verkeer goed. Ik kan bijvoorbeeld
> http://whatismyv6.com/ bereiken, en Google Maps. Maar ik kom niet bij
> Twitter (gelukkig maar, wellicht :-) ). Of komt dat omdat Twitter geen
> ipv6 doet en ik ip4 forwarding nog niet aan heb staan?
>
> in /etc/sysctl.conf staat forwarding uit..
>
> ,
> | # Uncomment the next line to enable packet forwarding for IPv4
> | #net.ipv4.ip_forward=1
Dat hekje weghalen, om IPv4 forwarding aan te zetten
> |
> | # Uncomment the next line to enable packet forwarding for IPv6
> | # Enabling this option disables Stateless Address Autoconfiguration
> | # based on Router Advertisements for this host
> | #net.ipv6.conf.all.forwarding=1
Dat hekje weghalen, om IPv6 forwarding aan te zetten, het is
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
>
> in shorewall6.conf
> staat
>
> IP_FORWARDING=Off
>
> en
>
> in shorewall.conf staat IP_FORWARDING=Keep
>
De vermeldde documentatie van
http://www.geeklk.com/2013/09/installing-openvpn-with-shorewall-in-ubuntu-part-2/
die zegt
Edit Shorewall config file enable IP Forwarding
${EDITOR:-nano} shorewall.conf
IP_FORWARDING=On
Groeten
Geert Stappers
--
Leven en laten leven
signature.asc
Description: Digital signature
openvpn script
Ik heb in een openvpn conf het volgende staan: ... script-security 2 route-delay 10 route-up /etc/openvpn/scripts/gaugino_up.sh down /etc/openvpn/scripts/gaugino_down.sh ... In gaugino.up staat het volgende: # /bin/bash /sbin/ip -6 addr add 2a02:898:62:2af2::2/64 dev tun1 21 | /usr/bin/logger -t ovpn_gaugino_up /sbin/ip -6 addr add 2a02:898:62:2afc:21c:c0ff:fe46:182a/64 dev eth0 21 | /usr/bin/logger -t ovpn_gaugino_up /sbin/ip -6 route add ::/0 dev tun1 metric 1 21 | /usr/bin/logger -t ovpn_gaugino_up echo /etc/openvpn/scripts/gaugino_up.sh has run | /usr/bin/logger -t ovpn_gaugino_up exit 0 Als ik openvpn restart krijg ik de volgende melding: Aug 27 15:11:54 custard ovpn-custard_to_gaugino[20546]: Route script failed: could not execute external program Hoe los ik dit op? -- Jaap van Wingerde e-mail: 1234567...@vanwingerde.net signature.asc Description: PGP signature
Re: openvpn script
On Sat, August 27, 2011 17:22, Jaap van Wingerde wrote: In gaugino.up staat het volgende: # /bin/bash Dat moet lijkt me '#! /bin/bash' zijn. -- Rutger van Sleen - http://djslash.org/ https://identi.ca/rvs - https://twitter.com/rvansleen - Systeembeheer en consultancy in open software - http://selkof.net/ - Voorzitter Nederlandse Linux Gebruikersgroep - http://nllgg.nl/ -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: openvpn script
On Sat, Aug 27, 2011 at 03:22:53PM +, Jaap van Wingerde wrote: Ik heb in een openvpn conf het volgende staan: ... script-security 2 route-delay 10 route-up /etc/openvpn/scripts/gaugino_up.sh down /etc/openvpn/scripts/gaugino_down.sh ... In gaugino.up staat het volgende: # /bin/bash /sbin/ip -6 addr add 2a02:898:62:2af2::2/64 dev tun1 21 | /usr/bin/logger -t ovpn_gaugino_up /sbin/ip -6 addr add 2a02:898:62:2afc:21c:c0ff:fe46:182a/64 dev eth0 21 | /usr/bin/logger -t ovpn_gaugino_up /sbin/ip -6 route add ::/0 dev tun1 metric 1 21 | /usr/bin/logger -t ovpn_gaugino_up echo /etc/openvpn/scripts/gaugino_up.sh has run | /usr/bin/logger -t ovpn_gaugino_up exit 0 Als ik openvpn restart krijg ik de volgende melding: Aug 27 15:11:54 custard ovpn-custard_to_gaugino[20546]: Route script failed: could not execute external program Hoe los ik dit op? Wat ik als eerste zou doen, is het controleren van wat er allemaal op een en dezelfde regel staat. Regels begrenzen op vierenzeventig tekens of zo, is prima. Een onverwachtte line wrap in een script kan echter fataal zijn. De afgebroken regels die op http://lists.debian.org/debian-user-dutch/2011/08/msg00085.html staan, is wat ik ook ontving. Ik kan mij voorstellen het slechts in het E-mail programma zit, maar ook dat het de oorzaak van het probleem is. Groeten Geert Stappers P.S. Deze regel is wel vel langer dan 74 tekens. Vergelijk eventueel http://lists.debian.org/debian-user-dutch/2011/08/ met wat je in je E-mail programma ziet. -- And is there a policy on top-posting vs. bottom-posting? Yes. -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: openvpn script
Op 2011-08-27T18:22:35+0200 schreef Rutger van Sleen djsl...@djslash.org in bericht 52d019888c78bc1f101fae457cc8d8ba.squir...@webmail.selkof.net, inzake Re: openvpn script, het volgende: Dat moet lijkt me '#! /bin/bash' zijn. Klopt. Hersteld. Helpt niet. -- Jaap van Wingerde e-mail: 1234567...@vanwingerde.net web: http://jaap.vanwingerde.net/ signature.asc Description: PGP signature
Re: openvpn script
Op 2011-08-27T19:01:22+0200 schreef Geert Stappers stapp...@stappers.nl in bericht 20110827170122.gs2...@gpm.stappers.nl, inzake Re: openvpn script, het volgende: Wat ik als eerste zou doen, is het controleren van wat er allemaal op een en dezelfde regel staat. Regels begrenzen op vierenzeventig tekens of zo, is prima. Een onverwachtte line wrap in een script kan echter fataal zijn. Het script functioneert naar behoren als ik het vanaf de command line uitvoer. Het probleem moet volgens mij met OpenVPN te maken hebben. -- Jaap van Wingerde e-mail: 1234567...@vanwingerde.net web: http://jaap.vanwingerde.net/ signature.asc Description: PGP signature
