Ausschließlich ich selbst möchte Zugriff auf die Daten haben.
Externer Service ist so eine Sache.
Für VPN brauchst Du keinen externen Service. Installiere z. B. Wireguard (oder gleichwertig) auf Server und Client, und Du hast dann eine VPN-Verbindung.
- sollte die Neuinstallation notwendig sein: lassen sich die Dateien von der SD mit
ext2explore auslesen, auf dem PC zwischenspeichern und wieder auf die Karte
kopieren. ist dies möglich und ratsam?
Die Neuinstallation für den PI3B+ mit bullseye, machst Du auf eine neue SD-Karte und die Daten von der alten SD-Karte kopierst Du direkt (und nicht via PC) am PI3B+ (... mit Adapter/Cardreader am USB-Anschluss des PI3B+).
... ext4 auf Partition2
Kannst Du das:
Quote... auf diesem einen symlink auf ein anderes Verzeichnis auf dem Stick machen will, dann wird mir der Link nicht auf dem USB-Stick gespeichert, sondern auf dem Pi, an dem der USB-Stick gerade hängt.
für die Partition2, mit einem Beispiel mal zeigen?
Also wenn ich z.B. einen USB-Stick anstöpsle und auf diesem einen symlink auf ein anderes Verzeichnis auf dem Stick machen will, dann wird mir der Link nicht auf dem USB-Stick gespeichert, ...
Welches Dateisystem hast Du auf dem USB-Stick?
Reicht das nicht auch?
Das reicht auch. Wichtig ist der Port 853 oder "domain-s".
Der nächste Befehl wurde mit einer Fehlermeldung beantwortet,
ip route add 0.0.0.0/0 via 192.168.178.5
keine route. Hast Du evtl. noch eine Idee?
Dann versuch mal mit:
ip route add default via 192.168.178.5BTW: Wie lautete diese Fehlermeldung, genau?
[…]
Die Ausgabe ist:
net.ipv4.ip_forward = 1
OK, das passt.
Ich bekomme regelmäßig
im unbound log. Failed
Hast Du in der config für unbound, für den jeweiligen DoT-Server, auch ein "hostname for TLS certificate validation" eintragen müssen? Oder gibt es die Möglichkeit diesen hostname dort einzutragen?
EDIT:
Beim unwind (dns resolver für DoT) den ich benutze, könnte ich solche "hostname for TLS certificate validation" eintragen, wenn ich sie kennen würde.
Wenn ich aber unwind im Vordergrund und verbose mode starte, sehe ich u. a. auch solche Zeilen:
[1660250403] libunbound[42774:0] debug: SSL connection authenticated ip4 185.228.168.9 port 853 (len 16)
[1660250403] libunbound[42774:0] debug: SSL connection authenticated ip4 217.0.43.114 port 853 (len 16)für die DoT-Server die ich in der config eingetragen habe. Wenn ich nach dem Start des unwind, dann eine Namensauflösung starte, bekomme ich vom unwind (verbose mode und noch immer im Vordergrund) z. B. solche Ausgaben:
[127.0.0.1]:41163: dresden.de. IN A ?
try_next_resolver[+0ms]: DoT[validating] dresden.de. IN A
try_next_resolver: could not find (any more) working resolvers
resolve_done[DoT]: dresden.de. IN A rcode: NOERROR[0], elapsed: 275ms, running: 1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
dresden.de. IN A
;; ANSWER SECTION:
dresden.de. 900 IN A 194.49.19.59
dresden.de. 900 IN A 194.49.19.60Ich verstehe das so, dass es sich um eine authentifizierte und verschlüsselte Verbindung zum DoT-Server handelt.
Die Frage ist ob es ein Linuxtool dafuer gibt oder andere Wege beschreiten muss
Man kann z. B. mit tcpdump schauen, zu welchem Server eine TCP-Verbindung via dst.-Port 853, hergestellt wird.
Sowas suche ich fuer DOT.
Für DoT gibt es z. B. in der FritzBox, so etwas:
QuoteEs wurde erfolgreich eine Verbindung - samt vollständiger Validierung - zu den verschlüsselten DNS-Servern aufgebaut
Die Erklärung dazu:
QuoteDiese Meldung ist eine Ereignismeldung aus dem Bereich "Internet".
Die Meldung informiert Sie darüber, dass erfolgreich eine Verbindung - samt vollständiger Validierung - zu den verschlüsselten DNS-Servern aufgebaut wurde. Sie können verschlüsselte DNS-Server unter "Internet / Zugangsdaten / DNS-Server" im Bereich "DNS over TLS (DoT)" einrichten.
Quelle: AVM-service
Wie man so eine Info in der Kommandozeile bekommen kann, weiß ich nicht.
Ich denke, wenn ich für DoT einen "validating DNS resolver" (z. B. unwind oder gleichwertig) benutze und dieser mit DoT die Namensauflösung erfolgreich liefert/durchführt, dann wird das schon OK sein.
Ich meine zu dem Absatz von Dir:
sudo iptables -t nat -I POSTROUTING 1 -o eth0 -j MASQUERADE
sudo iptables -t nat -I POSTROUTING 2 -o tun0 -j MASQUERADEWie ist auf dem PI (gateway) die Ausgabe von:
sysctl net.ipv4.ip_forward?
Aber ich moechte das auch noch exakt verifizieren
Was genau meinst Du mit "noch exakt verifizieren"?
EDIT:
Ich denke, das sniffen der syn-Flag-Anfrage und das rDNS, sollte doch exakt genug sein:
21:28:09.602623 dc:a6:32:cf:3f:38 3c:a6:2f:d3:0a:d6 0800 78: 1##.###.###.###.21850 > 185.228.169.9.853: SWE [tcp sum ok] 437301898:437301898(0) win 16384 <mss 1432,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 3820741027 0> (DF) (ttl 54, id 12363, len 64):~ #dig -x 185.228.169.9 +short
security-filter-dns2.cleanbrowsing.org.Deshalb macht man ja DoT, damit nicht viel gesehen wird. 
Ich habe nach einer sicheren Method gesucht wie ich unter Linux verifizieren kann dass DOT genutzt wird. Aber irgendwie bin ich nicht richtig fuendig geworden
Teste mal ob auf den TCP-Port 853 zugegriffen wird:
sudo tcpdump -c 100 -vvveni eth0 port 853 ... dem Rasp pi 4. Habe ihn zwar erfolgreich installiert - Internet, Mail, Büroanwendungen,Musik etc. laufen super
Aber mit dem RFID-Kartenleser und der AusweisApp2 habe ich mir zuviel zugemutet.
Hast Du auch schon die AusweisApp2 aus den packages probiert? Z. B.:
:~ $ apt-cache policy ausweisapp2
ausweisapp2:
Installed: (none)
Candidate: 1.22.0-1
Version table:
1.22.0-1 500
500 https://deb.debian.org/debian bullseye/main arm64 PackagesWenn ja, was hat nicht funktioniert?
Display Morehier die Ergebnisse vom der VU Plus Box 192.168.2.20
ip r
default via 192.168.2.1 dev eth0
169.251.0.0/16 dev eth0
192.168.2.0/24 dev eth0 src 192.168.2.20
ip r g 1.1.1.1
1.1.1.1 via 192.168.2.1 dev eth0 src 192.168.2.20
Das ist ein sehr sauberes Routing (auf der 192.168.2.20), aber nicht das was Du willst.
Nach dem Du die jetzige default route:
default via 192.168.2.1 dev eth0gelöscht hast, konfiguriere dort mal:
ip route add 192.168.178.5 via 192.168.2.1
ip route add 0.0.0.0/0 via 192.168.178.5Dann hast Du eine definierte Route zum VPN-Gateway 192.168.178.5, via den Router 192.168.2.1 und eine default route mit dem (VPN-)gateway 192.168.178.5.
Konfiguriere noch auf dem PI, das source-NAT (MASQUERADE, in der POSTROUTING chain und nat table) für die Interfaces eth0 und tun0 (bzw. das forwarding sollte auf dem PI schon konfiguriert sein).
Danach vom Receiver die Ausgaben von:
ip r
ip r g 1.1.1.1posten.
EDIT:
BTW: Für mtr kannst Du mtr-tiny installieren:
sudo apt install mtr-tinyDass das ganze Routing nicht sauber ist zeigt diese Aussage :
Sagen wir mal so, diese Aussage des TE (... betr. 2. Zitat im Beitrag #12), hilft nicht weiter bzw. ist nicht zielführend für sein Anliegen ... und hat auch einen kleinen Schönheitsfehler. Aber wir wissen doch, dass mit "Das Netz ist 192.168.178.1", das "192.168.178.0/24" gemeint ist.
Ob das Routing "bei dem Rechner aus dem gleichen Netz" sauber oder nicht sauber ist, wissen wir (noch) nicht, ... weil es für das was der TE will, auch nicht relevant war bzw. nicht relevant ist.
Wenn wir das trotzdem wissen wollen, müsste der TE uns vom PI und vom "Rechner aus dem gleichen Netz" (mit und ohne VPN-gateway), die entsprechenden/erforderlichen Informationen liefern. Z. B.:
ip a
ip r
arp -av
ip r g 1.1.1.1
mtr -4nr -c 1 1.1.1.1Mehr sage bzw. schreibe ich zu deinem Beitrag #12, jetzt nicht.
Dann einfach statische Routen in den PI 192.168.2.20
/etc/dhcpcd.confAuskommentieren
BTW: Die 192.168.2.20 ist nicht der PI. Siehe oben:
QuoteDer 192.168.2.20 ist eine Linux Sat Receiver - VU Uno 4k SE
... und ob die einen dhcpcd hat?
Die 192.168.2.20 (Linux Sat Receiver) hat auch keine <VPNIP>, sondern erreicht das VPN-Subnetz/gateway, via ihre default route mit dem gateway/Router 192.168.2.1 (siehe oben):
QuoteIch habe einen Rapsberry 4 im Einsatz und dort ein VPN Gateway installiert.
Das Netz ist 192.168.178.1 , das VPN Gateway des Raspberry 192.168.178.5
EDIT:
@TE:
Quote
Meine Frage betrifft ein mit dem 192.168.178.1 über openvpn konstant verbundenes Netzwerk 192.168.2.1
BTW: Die 192.168.178.1 wird eine FritzBox sein, oder? ... und was ist die 192.168.2.1 für ein Router? Hast Du auf der 192.168.2.1, den OpenVPN-Client installiert/konfiguriert?
Du musst die entfernten Netze in deinen Routern ( Default Gateways) bekannt machen.
Das hat er lt. seinen Beiträgen auch schon gemacht und es funktioniert auch:
Der 192.168.2.20 ist eine Linux Sat Receiver - VU Uno 4k SE
ip r g 192.168.178.5
192.168.178.5 via 192.168.2.1 dev eth0 src 192.168.2.20QuoteIch kann zwar mit Ping problemlos von dem Rechner 192.168.2.20 das VPN Gateway anpingen, ...
QuoteDie Rechner können sich gegenseitig anpingen, ...
Er will auf dem 192.168.2.20, den Internet-Traffic nicht über 192.168.2.1, sondern über 192.168.178.5 routen.
ich Stelle gerade fest, dass wenn ich auf dem 192.168.2.20 das gateway 192.168.178.5 aktiveren moechte, so wird das nicht gespeichert und das gateway deaktivert.
.... Woran könnte das liegen?
Das liegt daran, dass Du auf diesem Gerät wenn es im Subnetz 192.168.2.0/24 ist, keine definierte Route zum Gerät mit der IP 192.168.178.5 hast, und diese IP nur über die jetzige default route (mit dem gateway 192.168.2.1) erreichen kannst.
Machst Du die Konfiguration auf dem receiver über ein Web-Interface oder gibt es dort auch eine Kommandozeile?
Hat der receiver auch einen USB-Anschluss, so dass Du eine 2. NIC (via USB) dort benutzen könntest?
..., sobald ich das Gateway im 192.168.2.20 auf 192.168.178.5 stelle, bekommt der 192.168.2.20 keine internetverbindung mehr.
Dann poste vom 192.168.2.20, die Ausgaben von:
ip r
ip r g 1.1.1.1
arp -av
ping -c 3 1.1.1.1
host -t a heise.de 1.1.1.1, wenn Du im 192.168.2.20, das Gateway auf 192.168.178.5 gestellt hast.
... und vom PI (192.168.178.5) die Ausgaben von:
ip a
ip r
arp -av
sudo iptables -nvx -L -t nat
sysctl net.ipv4.ip_forward