selectief upgraden
Beste Lijst, Ik gebruik Debian Stretch (Stable) welke tijden de installatie Libre office 5.2 heeft geinstalleerd. Daar heb ik een probleempje mee wat wellicht opgelost is als ik hier een nieuwere versie van gebruik. Nu weet ik niet of het handig is om van stable naar testing over te stappen, maar is het ook mogelijk om testing in de repository toe te voegen en hier selectief gebruik van te maken? Fred
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: 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
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 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 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
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 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: printen via nas
Op 09-02-2020 om 08:15 schreef Frans van Berckel: Terug naar 2012, een mooie check list ... https://forums.linuxmint.com/viewtopic.php?f=51=80901=20 Heb je er zowel lpr als cupswrapper opgezet? Met vriendelijke groet, Ja dat heb ik. Inmiddels heb ik de link die jij gestuurd hebt doorgenomen en met aanpassing van apt install lib32z1 i.p.v ia32-libs en sudo mkdir /var/spool/lpd werkte het printen nu wel. Dit is echter vanaf de laptop met die nieuwe installatie. De laptop met de oudere maar eveneens met 'Buster' installatie print nog steeds niet. Overigens waren daar de genoemde /var/spool/lpd en /usr/share/cups/model wel aanwezig. Maar de installatie van bovengenoemde lib heeft er niet toe geleid dat het printen ook van deze laptop werkte. In elk geval is de nas uit te sluiten als boosdoener en kan ik me richten op de laptop met de oude installatie. mvg Fred
Re: printen via nas
Even vanaf mijn mobiel en niet op locatie. De ip adressen zitten in de range van 192.168.178.xx. op de enige router die ik gebruik. De nas is niet voorzien van een white list. Ik krijg ook geen foutmeldingen. Dat maakt het zoeken juist zo lastig. Cups geeft aan dat er wordt geprint en ook dat deze voltooid is. De drivers zijn alleen beschikbaar voor 32 bit terwijl de apparaten die ik gebruik 64 bit zijn. De drivers zijn geïnstalleerd met de --force-all optie. En blijkt op de desktop dus succesvol te werken. Op de laptops wordt de printer ook moeiteloos door cups gevonden. Er lijkt dus niets mis te zijn totdat ik op de zolder de print wil ophalen. Fred Verzonden door BlueMail Op 8 feb. 2020 13:16, om 13:16, Geert Stappers schreef: >On Sat, Feb 08, 2020 at 12:39:09PM +0100, Fred wrote: >> Beste lijst, >> >> Ik wil het volgende hier voorleggen omdat ik inmiddels niet meer weet >waar >> te zoeken. > >TOP, daarvoor is deze mailinglist. (Ja, dat is een compliment) > > >> Ik gebruik een brother printer type dpc195c die via usb op een >synology nas >> DS209+II via USB is aangesloten. Ik kan via een desktop pc (buster) >met deze >> printer printen. >> >> Via de laptop (buster) vind cups de printer ook maar kan niet >printen. >> voor een 2e laptop geldt ook dat hier de printer wel gevonden wordt >maar ook >> niet print. >> >> Vanaf beide laptops kan ik de nas wel benaderen. > >OK, dat betekent namelijk dat je _geen_ WIFI access point hebt >dat "client isolation" doet. > > >> Omdat ik al een tijd van voornemen was de eerste laptop te voorzien >van een >> nieuwe installatie leek mij dit juist een goed moment. Resultaat >hetzelfde; >> Printer wel gevonden en geinstalleerd maar geeft ondanks geen >foutmelding >> geen afdruk. >> >> Hopelijk krijg ik hier wat tips waarmee ik vanavond of vanacht verder >kan. > >Nou, op zijn minst deze ontvangstbevestiging en wat vragen? > >* Wat zijn de IP-adressen van de vier devices die nu genoemd zijn? > (Dezelfde vraag anders: Zit nog ergens een router tussen?) >* Die NAS, heeft die de desktop op een "white list" staan? >* Wat is eigenlijk de foutmelding die je krijgt? > (Wat zijn eigenlijk de foutmeldingen die je krijgt?) > > > >Groeten >Geert Stappers >-- >Leven en laten leven
printen via nas
Beste lijst, Ik wil het volgende hier voorleggen omdat ik inmiddels niet meer weet waar te zoeken. Ik gebruik een brother printer type dpc195c die via usb op een synology nas DS209+II via USB is aangesloten. Ik kan via een desktop pc (buster) met deze printer printen. Via de laptop (buster) vind cups de printer ook maar kan niet printen. voor een 2e laptop geldt ook dat hier de printer wel gevonden wordt maar ook niet print. Vanaf beide laptops kan ik de nas wel benaderen. Omdat ik al een tijd van voornemen was de eerste laptop te voorzien van een nieuwe installatie leek mij dit juist een goed moment. Resultaat hetzelfde; Printer wel gevonden en geinstalleerd maar geeft ondanks geen foutmelding geen afdruk. Hopelijk krijg ik hier wat tips waarmee ik vanavond of vanacht verder kan. Fred
printer perikelen
Ik ben alweer enige tijd bezig om mijn printer via een asus router aan de praat te krijgen. Ik moet zeggen met wisselend succes en de reden daarvoor begrijp ik niet. Het gaat om een brother DCP-195C die ik aan heb gesloten via een AT-AC68U Asus router en via Debian 10 wil laten printen. Het is een oude maar nog werkende printer en waar ik plezier zou hebben om deze aan de gang te krijgen. Zoals gezegd; Soms doet hij het wel en soms niet en dit is vooral jammer omdat hij het niet doet als ik heb nodig heb. Omdat o.a de drivers alleen voor de 32-bits pc zijn en de boel toch wat gedateerd is wil is toch opzoek naar een betrouwbare en onder linux goed werkende printer. Misschien dat ik daarvoor hier wat suggesties vind. Fred
Re: fonts, denk ik. Maar wellicht zit het elders
Gijs Hillenius wrote: knip Echter: ik merk nu dat ik geen Japanse, Chinese of andere unicode tekens meer zie. Volgens mij was dat eerder geen probleem. Ik verwacht bijvoorbeeld deze website te kunnen lezen http://en.wiktionary.org/wiki/%E7%9C%9F maar ik zie hier in plaats van een Japans/Chinees teken gewoon een leeg vierkantje. In Emacs (sorry hoor) zie ik, als ik tiep C-x 8 (enter) 771F (enter): 真 in plaats van het karakter... knip Ik heb *geen* idee waar ik moet beginnen met zoeken? Ik zie in /var/log/aptitude zo op het oog niet wat er op font-gebied (of locales) is vernieuwd. In verwijzing naar de interesse van voormelde Website welke bezocht is zoek eens op de volgende keywords: 'scim OR ibus AND debian'. scim en ibus zijn tools voor het ingeven van Chinese karakters waarbij fonts, locales etc. van wezenlijk belang zijn en misschien is daar de oplossing/oorzaak van het probleem te vinden/herleiden waarbij de link: http://isis.poly.edu/~qiming/chinese-debian-mini-howto.html een goeie start is. Fred -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
