[foobar]

Smartphone, ne so'n Schweinkram hat man als Hütchenträger net.

Wenn man weiß, was man tut (s.o.), kann man es durchaus benutzen. Aber wenn du nicht willst, lege dir halt einen Raspi zu so.

[Petrus]

Irgendwas hat mir meinen Ton kaputt gemacht, aber richtig. Weder die LinuxOS noch WindOS noch USB-Knoppix können derzeit damit dienen.

Retrospektiv war die letzte wissentlich 'kritische' Aktion, die zu so einem gravierenden Fehler hätte führen können, dass ich ausnahmsweise in Firefox (v60.0, updated) auf ZDF WM geguckt habe, mit deren Player . Am nächsten Tag gab's keinen Sound mehr.

Ich habe keine speziellen Sound-Setups, bisher funktionierte alles einfach über die üblichen Verdächtigen pulseaudio und alsa mit den default Einstellungen. Bei meiner bisherigen Odyssee nach einer Lösung habe ich auch testweise die alsa-base.conf und default.pa mit allen möglichen Ergänzungen bearbeitet, aber keine der Ideen fruchtete. Ein erfolgreiches BIOS-Update auf die aktuelle Version war meine letzte Hoffnung. Daran liegt's aber scheinbar auch nicht.

Ich habe ein MSI Board und eine Nvidia GPU. Wenn man das ganze Problem auf eine konkrete Frage zuspitzen könnte, würde ich fragen:

Warum wird der Onboard Sound Controller in lspci aufgelistet, aber aplay kann ihn nicht sehen?

Ich denke, das liegt irgendwie an den Treibern. Alsa schaltet laut dmesg, wenn der Standard Linux Sound Treiber namens snd-hda-intel (hat scheinbar nichts mit Intel direkt zu tun, die Bezeichnung ist eher ein Relikt) eingesetzt wird, MSI einfach ab. Offenbar gab es mal einige technische Probleme zwischen nvidia und MSI, das ist also vermutlich gewollt und sinnvoll. Ob es tatsächlich an diesem Vorgang liegt, dass der Onboard Controller nicht ins System findet weiß ich nicht. Klingt vielleicht danach, aber das wäre dann ja ein Linux Treiber Problem irgendwie. Und dass sowas bei drei unterschiedlichen Installationen (plus Windows) gleichzeitig auftritt.... ne, das muss an was anderem liegen.

Hier ist der wie ich finde sehr informative Output von diesem Alsa Script Dings.

Bitte bitte zu Hülf.

[foobar]

Wenn weder Windows noch Linux den Chip ansteuern können, obwohl es vorher ging, spricht einiges für einen Hardwaredefekt. Du kannst nochmal im BIOS-Setup nachgucken, ob der Chip wirklich aktiv ist (oft kann man ihn abschalten). Und was man mal probieren kann (hilft wahrscheinlich nicht, ist aber einfach zu machen): Rechner herunterfahren, den Hauptschalter am Netzteil umlegen, Stromkabel abziehen, 10 Minuten warten (damit sich alle Kondensatoren entladen können) und dann alles wieder einschalten. In ausgesprochen seltenen Fällen hilft's.

Persönlich werfe ich Pulseaudio immer vom System, weil der gerne auch Probleme macht, zusätzliche Komplexität einführt und in meinem Fall nichts bietet, was ALSA nicht bereits selbst beherrscht. Wenn allerdings Windows auch auf einmal keinen Ton mehr hat, würde ich ihn dieses Mal für unschuldig halten. Außerdem führt das Deinstallieren von PulseAudio auch zu Nebenwirkungen. Beispielsweise hat Mozilla, in ihrem eifrigen Bestreben, sich selbst irrelevant zu machen, PulseAudio als einzige Audioschnittstelle für FF auf Linux erklärt. Ohne PA kein Ton im FF. Dämlich geht die Welt zugrunde oder wie ging der Spruch?

[Lookbehind]

Dinge die mir bei Sound-Problemen immer schnell einfallen:
1. Irgendein Regler auf Null gedreht oder gemutet? Hier hilft Alsa oft, weil es nicht nur die Software-Regler anzeigt, sondern auch die Hardware-Regler, was erklären könnte, warum auch unter Windows kein Sound mehr da ist.
2. Grafikkarten! Wenn irgendwelche lustigen Plugins die Medien-Wiedergabe übernehmen, insbesondere mit DRM-Kram drin, wird gerne mal der HDMI-Ausgang als Primäre Soundkarte eingestellt. HDMI kann theoretisch auch Ton übertragen. Aber die meisten Leute haben ihre Lautsprecher separat über Klinke angeschlossen, und dann ist HDMI der falsche Ausgang. Oft bedeutet das, dass die Grafikkarte fälschlicherweise als aktive Soundkarte eingestellt wurde. Auch das kann Alsa umschalten.

Also vielleicht mal ein bisschen mit alsamixer rum spielen. (Terminal-Programm)

[Petrus]

Und was man mal probieren kann (hilft wahrscheinlich nicht [...] In ausgesprochen seltenen Fällen hilft's.

Ich glaube, das war's. Kurz nachdem ich das Posting hier verfasst hatte, hab ich mal den Rechner ausgeschaltet, alles abgetrennt und aufgemacht. Die ganze Aktion dauerte sicher länger als 10 Minuten. Nach dem ersten Boot in Solus waren die Kopfhörer definitiv nicht da. Es wäre ja auch zu schön gewesen, aber dann nach der Eingabe von sudo usermod -aG audio `whoami` wurden sie plötzlich angezeigt. Ich hab das unerwartete Funktionieren eigentlich nicht mit dem Befehl in Verbindung gebracht, zumal ja nun auch Ubuntu wieder willens war. Also, Kondensatoren... entleeren... ok.

Ansonsten war's mal eine Gelegenheit eine weitere Ecke von Linux etwas genauer zu beleuchten. Und FF und der ZDF media player, naja. Das nächste Mal versuche ich den Stream halt über VLC oder gnome-mpv zu schauen.

Also vielleicht mal ein bisschen mit alsamixer rum spielen. (Terminal-Programm)

Jup, habs mir installiert und als der Onboard-Sound wieder verfügbar war sogar benutzt. Bei Solus lief direkt alles wieder, bei Ubuntu brachte eine remove --purge Aktion von pulseaudio und alsa leider nichts, so dass ich die default.pa mit Ergänzungen bearbeiten musste. Nun läufts auch dort wieder.

Danke euch für die schnelle Hilfe.

[foobar]

aber dann nach der Eingabe von sudo usermod -aG audio `whoami` wurden sie plötzlich angezeigt.

Ob es an sowas liegt, kann man immer dadurch testen, dass man es vorher einmal als root probiert. Funktioniert es dann, liegt's an fehlenden Rechten am jeweiligen Audiodevice und ein Hinzufügen des Users zur Gruppe "audio" kann das Beheben (so denn die Rechte am Device entsprechend gesetzt sind).

Kann root auch nichts abspielen, hilft auch keine Gruppenmitgliedschaft für den gemeinen User weiter.

[Petrus]

Meinst du das so? sudo vlc mediadatei.mp4 könnte wegen fehlender Rechte funktionieren, obwohl aplay -l das Device gar nicht listet? Ich bin ja eigentlich nur meinen Headphones hinterhergelaufen die ganze Zeit.

Übrigens würde mich interessieren, wie Linux das genau macht, wenn Dateien von einer NTFS-Platte auf eine ext4-Platte geschrieben werden. Und an welcher Stelle dieses Vorgangs wären Fehler denkbar? Linux musste ja das NTFS Format irgendwie nachbauen oder? Wie haben sie's grob gemacht? Und ist das dann userspace oder kernelspace?

[foobar]

Meinst du das so? sudo vlc mediadatei.mp4 könnte wegen fehlender Rechte funktionieren, obwohl aplay -l das Device gar nicht listet? Ich bin ja eigentlich nur meinen Headphones hinterhergelaufen die ganze Zeit.

Antwort von Radio Eriwan: Im Prinzip ja, allerdings hilft es immer, Vorgänge und Tests so einfach wie möglich zu halten. VLC ist ein komplexes, grafisches Programm. Das kann schon daran scheitern, dass es nicht auf dein X-Display zugreifen darf. Besser ist es, man verwendet nur einfache Kommandozeilenprogramme. aplay, alsaplayer, mpg123, solche Geschichten.

Hier direkt mit 'sudo' zu arbeiten, ist nicht ganz unproblematisch. Anfängern ist häufig nicht klar, wo die Shell die Grenze zieht zwischen der Benutzer- und der root-Umgebung. Beispiel:
'sudo cat mysound.wav | aplay' führt aplay nicht mit root-Rechten aus. Am besten holt man sich mit 'sudo -i' bzw. 'sudo su -' eine richtige root-Shell und arbeitet darin.

Aber wie gesagt, wenn 'aplay -l' und 'cat /proc/asound/cards' nichts finden, dann sind entweder die Treiber nicht geladen, oder sie konnten die Hardware nicht finden bzw. richtig initialisieren. Das ist dann oft ein Problem mit der Hardware.

Übrigens würde mich interessieren, wie Linux das genau macht, wenn Dateien von einer NTFS-Platte auf eine ext4-Platte geschrieben werden.

Oweh. Das ist mal wieder so 'ne Frage. Allgemein und vereinfacht läuft es so, dass Linux diese Dinge abstrahiert. Es gibt ein sogenanntes VFS (Virtual File System) und das stellt generische Schnittstellen für den Kernel zur Verfügung. Wenn man z.B. eine bestimmte Datei finden will, ruft man eine Funktion im VFS auf ("namei") und das VFS delegiert die Sache dann an den jeweiligen Treiber für das betroffene Dateisystem. Dessen Job ist es, Anfragen vom VFS anzunehmen und zu beantworten.

Alles über dem VFS (restlicher Kernel, Userspace-Programme wie 'cp', etc.) braucht sich keinen Kopp darum zu machen, welche Dateisysteme involviert sind. Das wird alles vom VFS versteckt.

Und an welcher Stelle dieses Vorgangs wären Fehler denkbar?

Öhm... an jeder? Klingt doof, ist aber so. Die einzige prinzipiell fehlerfreie Aktion ist die, die nicht stattfindet.

Linux musste ja das NTFS Format irgendwie nachbauen oder? Wie haben sie's grob gemacht? Und ist das dann userspace oder kernelspace?

Ja, das musste "nachgebaut" werden. Es gab mehrere Versuche, die aktuell i.d.R. verwendeten Treiber sind der dritte und heißen deshalb auch ntfs-3g. Die werden in einem dualen Lizenzmodell von Tuxera entwickelt. Die haben auch IIRC eine Vereinbarung mit MS getroffen. Die früheren Treiber waren im Kernelspace, ntfs-3g basiert auf FUSE (Filesystem in Userspace). Dabei liegt nur noch ein allgemeines Modul im Kernelspace, das die Anfragen des VFS entgegen nimmt. Das Modul ist aber selbst nur ein Wrapper und reicht den Kram nach außen, in den Userspace weiter. Dort kann ihn ein "normales" Programm verarbeiten und dann an das FUSE-Model im Kernel zurück reichen, welches nun seinerseits das VFS bedient.

Synlogy hat dazu ein schickes Schaubild veröffentlicht: https://blog.synology.com/?p=1111

Natürlich ist damit eine Leistungseinbuße verbunden, aber die ist oft vernachlässigbar. Und da man im Userspace weniger stark reglementiert ist (beim Kernel haben dessen Entwickler halt ein Auge auf den Code), gibt es dank FUSE auch ein paar durchaus interessante Implementierungen von Dateisystemen, die es andernfalls so nicht gegeben hätte. Neben ntfs-3g ist das z.B. SSHFS zum Mounten von entfernten Rechnern via SSH oder curlftpfs, mit dem sich FTP-Server mounten lassen.

Übrigens ist FUSE zwar prinzipiell mit einem Performanceverlust verbunden, aber das heißt nicht, dass es andere Faktoren es nicht trotzdem zur besseren Wahl machen. Ein aktuelles Beispiel: Vor einiger Zeit brauchte ich ein neues Backup-Programm, da das bisher verwendete obnam nicht mehr weiter entwickelt wurde. Lookbehind hatte hier schon mal von storeBackup vorgeschwärmt, also dachte ich, es sei einen Blick wert. Leider gab es ein Problem: Das Backup sollte via CIFS/SMB auf ein NAS erfolgen und das tat sich schwer mit Symlinks. Mit obnam war das kein Problem, weil das die Backups in eigene Container packt. Aber storeBackup will die Dateien direkt sichern.

Natürlich lief auf dem NAS letztlich auch nur ein Linux mit Samba und das Samba auf meinen PCs hatte keine Probleme mit Symlinks. Aber das Samba auf dem NAS war irgendwie anders konfiguriert und stolperte darüber. Und großartig was einstellen konnte man in der Web-GUI auch nicht dazu. NFS wäre eine Alternative gewesen, aber meine Messungen zeigten, dass es viel zu langsam war. Zehntausend Testdateien mit je 1 KB an Zufallsdaten auf das NAS zu kopieren dauerte via CIFS ca. 4:40 Minuten. Via NFS waren es dann über 15 Minuten. Hatte mich schon damit abgefunden, doch wieder ein Backup-Programm mit Datencontainern zu suchen, als ich - als letzten Schuss ins Blaue - den Shellzugang via SSH auf dem NAS aktivierte und die Messung mit SSHFS wiederholte. Viel Hoffnung hatte ich nicht. Das Dateisystem läuft im Userspace via FUSE und dann noch die bei SSH übliche Verschlüsselung, das konnte auf der schwachbrünstigen NAS-CPU ja nur bis zum Sankt Nimmerleinstag dauern. Entsprechend war ich ziemlich vom Hocker gehauen, als das Kopieren in unter zwei Minuten erledigt war. Und Symlinks waren auch kein Problem.

Ich habe bis jetzt noch nicht so richtig ausbaldowert, warum das so ist. Eigentlich müsste SSHFS langsamer sein. Eventuell hat der ARM-Prozessor eine Funktionseinheit, die die Verschlüsselung in Hardware macht oder irgendeine Effizienz beim Netzwerkprotokoll macht alle Nachteile wieder wett oder der CIFS- und NFS-Server auf dem NAS sind wirklich scheiße konfiguriert (aber warum sollten sie, wenn das der Kram ist, den die meisten Leute nutzen werden?).

Fest steht, dass das FUSE-Dateisystem zumindest hier, in diesem Fall, schneller war als das im Kernel implementierte Netzwerkdateisystem CIFS. Man sollte FUSE also nicht unterschätzen.

[Uripura]

Hat sich jemand mal mit WireGuard auseinandergesetzt?
Ich habe heute den ganzen Tag nach dieser Anleitung versucht einen VPN Tunnel mit meinem Server zu erstellen.
Der Tunnel wird zwar aufgebaut, aber es geht z.B. vom Browser nichts durch. Den Endpoint kann ich anpingen aber nicht weiter raus.

WireGuard soll angeblich viel einfacher sein als OpenVPN oder IPsec, aber ich verzweifele gerade ein wenig daran.

Ich vermute mal, es liegt irgendwo am Server.

Config vom Client

[Interface]
Address = 10.0.0.2/24, fd00::0002/120
PrivateKey = [schlüssel]
DNS = 10.0.0.1, fd00::0001

[Peer]
PublicKey = [schlüssel]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = uripura.de:4711
PersistentKeepalive = 25

Config vom Server

[Interface]
ListenPort = 4711
Address = 10.0.0.1/24, fd00::0001/120
PrivateKey = [schlüssel]

PostUp = iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostUp = iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostUp = iptables -A INPUT -p udp -m udp --dport 4711 -m conntrack --ctstate NEW -j ACCEPT
PostUp = iptables -A INPUT -s 10.0.0.0/24 -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
PostUp = iptables -A INPUT -s 10.0.0.0/24 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
PostUp = iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

PostDown = iptables -D INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostDown = iptables -D FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostDown = iptables -D INPUT -p udp -m udp --dport 4711 -m conntrack --ctstate NEW -j ACCEPT
PostDown = iptables -D INPUT -s 10.0.0.0/24 -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
PostDown = iptables -D INPUT -s 10.0.0.0/24 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

#ipv6
PostUp = ip6tables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostUp = ip6tables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostUp = ip6tables -A INPUT -p udp -m udp --dport 4711 -m conntrack --ctstate NEW -j ACCEPT
PostUp = ip6tables -A INPUT -s fd00::/120 -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
PostUp = ip6tables -A INPUT -s fd00::/120 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
PostUp = ip6tables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
PostUp = ip6tables -t nat -A POSTROUTING -s fd00::/120 -o eth0 -j MASQUERADE

PostDown = ip6tables -D INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostDown = ip6tables -D FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostDown = ip6tables -D INPUT -p udp -m udp --dport 4711 -m conntrack --ctstate NEW -j ACCEPT
PostDown = ip6tables -D INPUT -s fd00::/120 -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
PostDown = ip6tables -D INPUT -s fd00::/120 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
PostDown = ip6tables -D FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
PostDown = ip6tables -t nat -D POSTROUTING -s fd00::/120 -o eth0 -j MASQUERADE

[Peer]
PublicKey = [schlüssel]
AllowedIPs = 10.0.0.2/32, fd00::0002/128
PersistentKeepalive = 25

Das sind noch die Ausgaben von

root@client# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.0.2/24 dev wg0
[#] ip address add fd00::0002/120 dev wg0
[#] ip link set mtu 1412 dev wg0
[#] ip link set wg0 up
[#] resolvconf -a wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0

root@client# ip route
default via 192.168.178.1 dev wlan0 
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.2 
192.168.178.0/24 dev wlan0 proto kernel scope link src 192.168.178.12

[Lookbehind]

Was versuchst du denn "weiter raus" zu erreichen? Andere Systeme im 10.0.0.0/24 Netz? Oder was anderes?
Wenn du z.B. über den Tunnel aufs Internet zugreifen möchtest, würden mir spontan 2 Dinge komisch vorkommen.

1. PostUp = iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT Hier sind input und output-interface das gleiche. Er kann also nicht über andere Interfaces routen. Da wg0 vermutlich ein virtuelles Interface ist, welches nur für Wire-Guard existiert, wird da wahrscheinlich auch nix anderes als das 10.0.0.0/24 Netz drüber erreichbar sein.

2. Das Clientseitige Routing passt auch nicht, um die Daten übers VPN zu routen.

Falls du andere Systeme im 10.0.0.0/24 Netz erreichen möchtest. Wie sieht denn ein Traceroute auf den VPN-Server aus, und wie einer auf das eigentliche Ziel?
Und was ist deine Policy in iptables?

PS.: Ich habe keinerlei Erfahrungen mit WireGuard. Wohl aber mit OpenVPN. Deine Beschreibung klingt weniger nach einem VPN-Problem an sich, als nach einem generellen Netzwerk/Routing-Problem.

... ach ja. Auf welchem Layer arbeitet WireGuard?

[Uripura]

Was versuchst du denn "weiter raus" zu erreichen? Andere Systeme im 10.0.0.0/24 Netz? Oder was anderes?
Wenn du z.B. über den Tunnel aufs Internet zugreifen möchtest, würden mir spontan 2 Dinge komisch vorkommen.

1. PostUp = iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT Hier sind input und output-interface das gleiche. Er kann also nicht über andere Interfaces routen. Da wg0 vermutlich ein virtuelles Interface ist, welches nur für Wire-Guard existiert, wird da wahrscheinlich auch nix anderes als das 10.0.0.0/24 Netz drüber erreichbar sein.

2. Das Clientseitige Routing passt auch nicht, um die Daten übers VPN zu routen.

Falls du andere Systeme im 10.0.0.0/24 Netz erreichen möchtest. Wie sieht denn ein Traceroute auf den VPN-Server aus, und wie einer auf das eigentliche Ziel?
Und was ist deine Policy in iptables?

PS.: Ich habe keinerlei Erfahrungen mit WireGuard. Wohl aber mit OpenVPN. Deine Beschreibung klingt weniger nach einem VPN-Problem an sich, als nach einem generellen Netzwerk/Routing-Problem.

... ach ja. Auf welchem Layer arbeitet WireGuard?

Ich möchte über das VPN das Internet erreichen. Ich möchte von meinem Laptop aus über meinen Server gehen.
Das 10.0.0.0/24 Netz ist nur für die eigentliche Verbindung zwischen Client und Server, da ist sonst nichts.

Hmm, mit iptables kenne ich mich nicht so aus, ich habe es einfach so von der Seite kopiert.
Aber ja, wg0 ist das virtuelle Interface für das VPN.

Das komische ist, dass es mit einem Test-VPN Account funktioniert den ich mir bei einem anderen Anbieter angelegt habe.

Aber wenn ich meine Config nehme, und über die Konsole meine öffentliche IP-Adresse abfrage, wird mir die von meinem Server angezeigt, so wie es sein soll.
Also scheint es doch zu funktionieren, aber eben nur über die Konsole.

IEin Tracepath funktioniert auch. Aber andere Anwendungen wie Firefox oder Thunderbird funktioniert nach wie vor nicht.

root@client /etc/wireguard# tracepath worldofplayers.de
 1?: [LOCALHOST]                      pmtu 1412
 1:  10.0.0.1                                             19.810ms 
 1:  10.0.0.1                                             19.812ms 
 2:  gw02.netcup.net                                      20.175ms 
 3:  juniper2.rz2.hetzner.de                              23.512ms asymm  4 
 4:  core21.fsn1.hetzner.com                              25.486ms 
 5:  ex9k2.dc6.fsn1.hetzner.com                           25.057ms 
 6:  www02.worldofplayers.de                              26.504ms reached
     Resume: pmtu 1412 hops 6 back 7

Ja, ich denke, dass das eher am Routing liegt, aber ich bin mit meinem Latein am Ende, ich habe es so gemacht wie in der Config die problemlos funktioniert.
Ich glaube, das Problem muss irgendwo am Server liegen.

Es arbeitet auf IP-Ebene, also Layer 3.

[Uripura]

Ich habe das Problem gelöst, es lag an der MTU. Per default ist die von 1500 auf 1412 heruntersetzt, das scheint nicht zu reichen (siehe hier), denn wenn ich es auf 1360 setze funktioniert alles.

Das erklärt auch warum tracepath und ping funktionierten während alles andere nicht ging, der Browser sendet natürlich mehr Daten als nur ein ping und dass ging wohl über die maximale MTU.

Die ganzen Regeln für iptables sind auch größtenteils verschwunden.
Meine Config sieht nun wie folgt aus.

Server:

root@server /etc/wireguard# cat wg1.conf 
[Interface]
ListenPort = 4711
Address = 10.0.0.1/24, fd00::0001/120
MTU = 1360
PrivateKey = [pubkey]
PostUp = iptables -A FORWARD -i wg1 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg1 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg1 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg1 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = [privkey]
AllowedIPs = 10.0.0.2/32, fd00::0002/128
PersistentKeepalive = 25

Client:

root@arschipad /etc/wireguard# cat wg1.conf 
[Interface]
PrivateKey = [privkey]
Address = 10.0.0.2/24, fd00::0002/120
MTU = 1360
DNS = 10.0.0.1, fd00::0001

[Peer]
PublicKey = [pubkey]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = uripura.de:4711
PersistentKeepalive = 25

Und was ich noch vergessen habe zu erwähnen ist, dass es wichtig ist, auf dem Server ip forwarding einzuschalten.
Dazu muss man nur

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

In die /etc/sysctl.conf schreiben und mit sysctl -p alles neu laden.

Diese Verbindung funktioniert nun für IPv4 und IPv6.

[Lookbehind]

...
Es arbeitet über UDP, also Layer 4.

Ich meinte eigentlich das Netz, was vom VPN aufgespannt wird.
Klassischerweise verwendet OpenVPN zum Beispiel ein Layer 3-Netz für tun-Devices und ein Layer 2-Netz für TAP-Devices. (Is ganz praktisch, wenn man mal alte Spiele übers Netz zocken möchte, die IPX oder son Kram verlangen.)

Ich habe das Problem gelöst, es lag an der MTU. Per default ist die von 1500 auf 1412 heruntersetzt, das scheint nicht zu reichen (siehe hier), denn wenn ich es auf 1360 setze funktioniert alles.

Das erklärt auch warum tracepath und ping funktionierten während alles andere nicht ging, der Browser sendet natürlich mehr Daten als nur ein ping und dass ging wohl über die maximale MTU.

Ah, die MTU ... an die hab ich kurzzeitig auch schon gedacht, aber gesehen, dass die ja schon reduziert ist und ... "wird schon passen"
Mögliche Erklärung: Dein Server ist ein vServer? Schau mal, was der für eine MTU eingestellt hat. Manchmal wird die bei virtualisierten Maschinen schon wegen der Virtualisierung reduziert.

Die ganzen Regeln für iptables sind auch größtenteils verschwunden.
Meine Config sieht nun wie folgt aus.

Server:

root@server /etc/wireguard# cat wg1.conf 
[Interface]
ListenPort = 4711
Address = 10.0.0.1/24, fd00::0001/120
MTU = 1360
PrivateKey = [pubkey]
PostUp = iptables -A FORWARD -i wg1 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg1 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg1 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg1 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = [privkey]
AllowedIPs = 10.0.0.2/32, fd00::0002/128
PersistentKeepalive = 25

Und die iptables Regeln sehen auch deutlich sinnvoller aus.

...
Und was ich noch vergessen habe zu erwähnen ist, dass es wichtig ist, auf dem Server ip forwarding einzuschalten.
Dazu muss man nur

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

In die /etc/sysctl.conf schreiben und mit sysctl -p alles neu laden.
...

Ok, das wiederum war für mich so selbstverständlich, dass ich es nicht für erwähnenswert hielt.

[Uripura]

Ich meinte eigentlich das Netz, was vom VPN aufgespannt wird.
Klassischerweise verwendet OpenVPN zum Beispiel ein Layer 3-Netz für tun-Devices und ein Layer 2-Netz für TAP-Devices. (Is ganz praktisch, wenn man mal alte Spiele übers Netz zocken möchte, die IPX oder son Kram verlangen.)

Ah, die MTU ... an die hab ich kurzzeitig auch schon gedacht, aber gesehen, dass die ja schon reduziert ist und ... "wird schon passen"
Mögliche Erklärung: Dein Server ist ein vServer? Schau mal, was der für eine MTU eingestellt hat. Manchmal wird die bei virtualisierten Maschinen schon wegen der Virtualisierung reduziert.

Und die iptables Regeln sehen auch deutlich sinnvoller aus.


Ok, das wiederum war für mich so selbstverständlich, dass ich es nicht für erwähnenswert hielt.

Das Netz? Das ist einmal ein IPv4 Netz im 10.0.0.0/24 und als IPv6 im fd::/120 Netz. Ich brauche nur jeweils zwei Adressen, einmal für den Server und einmal für den Client.
Aber sonst ist da nichts, das geht rein auf der IP-Ebene. WireGuard ist ein ganz simples Ding was nur ein virtuelles Interface aufmacht.
Die Präsentationen schaffen vielleicht ein wenig Klarheit.
Und es funktioniert so ähnlich wie SSH, man muss nur Schlüssel austauschen und dann ist man fertig.

Das ist auch so das schöne daran, es ist komplett im Kernel was es im Gegensatz zu Userspace Sachen wie OpenVPN sehr schnell macht.
Und es besteht nur aus ~4k LoC was es sehr klein, übersichtlich und einfach zu evaluieren macht.

Ja, ich habe einen vServer, aber bei dem ist die MTU auch 1500. Deswegen habe ich das auch erst ausgeschlossen.

Wie gesagt, mit iptables kenne ich mich gar nicht aus, ich habe es einfach nach Anleitung gemacht.

Das hatte ich natürlich schon von Anfang an, ich fand es nur erwähnenswert falls das jemand auch mal ausprobieren möchte. Falls jemand mal auf meinen Post stößt sollte da alles nötige drin stehen.

[Lookbehind]

Das Netz? Das ist einmal ein IPv4 Netz im 10.0.0.0/24 und als IPv6 im fd::/120 Netz. Ich brauche nur jeweils zwei Adressen, einmal für den Server und einmal für den Client.
Aber sonst ist da nichts, das geht rein auf der IP-Ebene.

Layer 3 also.

...
Und es funktioniert so ähnlich wie SSH, man muss nur Schlüssel austauschen und dann ist man fertig.

Das ist auch so das schöne daran, es ist komplett im Kernel was es im Gegensatz zu Userspace Sachen wie OpenVPN sehr schnell macht.
Und es besteht nur aus ~4k LoC was es sehr klein, übersichtlich und einfach zu evaluieren macht.

Ok, wenn eine Punkt zu Punkt-Verbindung auf Layer 3 alles ist, was man braucht, ist das sicher ne coole Sache. Muss ich mir mal merken.

...
Wie gesagt, mit iptables kenne ich mich gar nicht aus, ich habe es einfach nach Anleitung gemacht.

Wirkt anfangs schlimmer als es ist. So kompliziert ist das gar nicht. ... allerdings, wenn du da schon Lernaufwand rein steckst, dann besser gleich nftables.

Das hatte ich natürlich schon von Anfang an, ich fand es nur erwähnenswert falls das jemand auch mal ausprobieren möchte. Falls jemand mal auf meinen Post stößt sollte da alles nötige drin stehen.

Guter Mann

[Uripura]

Layer 3 also.

Das habe ich weiter oben schon korrigiert.

Ok, wenn eine Punkt zu Punkt-Verbindung auf Layer 3 alles ist, was man braucht, ist das sicher ne coole Sache. Muss ich mir mal merken.

Auf jeden Fall, gut ist auch, dass damit Roaming kein Problem ist. Man kann also mit dem Laptop einfach von WLAN zu LAN wechseln und der Tunnel bleibt bestehen.

Wirkt anfangs schlimmer als es ist. So kompliziert ist das gar nicht. ... allerdings, wenn du da schon Lernaufwand rein steckst, dann besser gleich nftables.

Hat denn jemand mal was gutes dazu geschrieben wo man das mal durchgehen kann? Aus der Manpage werde ich nicht so schlau weil da nicht so wirklich steht warum man was macht.

Guter Mann

Immer doch.

[Lookbehind]

...
Hat denn jemand mal was gutes dazu geschrieben wo man das mal durchgehen kann? Aus der Manpage werde ich nicht so schlau weil da nicht so wirklich steht warum man was macht.
...

Hm, ich hab mich damals einfach beim UbuntuUsers-Wiki bedient. Allerdings hatte ich da auch das Thema Paketfilter schon grob verstanden.

[Uripura]

Hm, ich hab mich damals einfach beim UbuntuUsers-Wiki bedient. Allerdings hatte ich da auch das Thema Paketfilter schon grob verstanden.

Nun Paketfilter verstehe ich auch so im groben, nur diese Syntax finde ich so kompliziert. Eine Weile habe ich mal mit ufw rumprobiert, das fand ich um einiges angenehmer.

[Lookbehind]

Ach Syntax ... dafür gibts Google

[foobar]

Ach Syntax ... dafür gibts Google

Die heutige Jugend! Manpages, Kinner. Manpages.