Was hast Du für das VPN eingerichtet? OpenVPN? IPSec?
Portforwarding auf den VPN-Server eingerichtet?
OpenVPN: 1194/UDP 1194/TCP
IPSec: 500/UDP (IKE), 4500/UDP (NAT-Traversal)
In der Client Config ist bei remote der richtige Sever eingetragen?
IPSec aus dem internem Netz geht auf die externe Adresse nicht, dazu müsste der Client aus den LAN/WiFi raus und über mobiles Netz testen.
Du kommst und sagt, dass es mit den IPv4-tools nichts bringt:
CodeDer map bringt auch nur was wenn die Rechner im gleichem Netz sind oder Routing da hin klappen würde.Hättest Du nur deine IPv6-tools empfohlen, dann hätte es diesen Austausch bzw. diese Diskussion gar nicht gegeben.
Das der nmap nicht bringt bezog sich eben hauptsächlich auf IPv4.
Also jetzt mal folgendes: Schalte endlich mal Dein IPv6 an und beschäftige Dich damit endlich mal.
Im Gegensatz zu IPv4 gibt es dort keine Broadcasts. Dementsprechend kann es auch kein ARP (Address Resolution Protocol) zur Zuordnung der IP-Adressen zu MAC-Adressen geben. Das ARP wird in IPv6 durch das Neighbor Discovery Protocol (NDP) abgelöst.
Eine IPv6 Address (fe80::6a37:e9ff:fe54:8d3d) liegt auf einem link.
Möchte ich jetzt Daten an fe80::9d43:500:86a4:5a3d hinschicken benötigt mein Interface die MAC-Adresse des anderen Interfaces.
wird ein Neighbor Solicitation Paket verschickt, wie beim früheren Arp Request.
Das Interface kennt die Mac Adresse nicht und es gibt kein Broadcast. Daher wird ein Multicast versendet. Der an eine Solicited Node Adresse verschickt wird. Diese gibt es auf Layer 2 und auf Layer 3. Beide enthalten die letzten 24 Bit der Ziel-IP-Adresse. In unserem Fall wäre dies: a45a3d.
Diesen 24 Bit werden zu Bildung der Multicast-Adressen festgelegte Präfixe voran gestellt:
Layer 3: ff02:0:0:0:0:1:ff00::/104 + a45a3d = ff02::1:ffa4:5a3d
Layer 2: 33:33:00:00:00 + a45a3d = 33:33:a4:5a:3d
Im Gegensatz zu ARP, wo alle Rechner im Netz damit zugefüllt werden bekommen nur die Rechner die Multicast die Pakete, die sie bekommen sollen. Deren IP-Adresse als letzte 24 Bit den Wert a45a3d enthält.
Bekommen Rechner das Paket, die wissen wo die fe80::9d43:500:86a4:5a3d hingehört, senden sie eine so genanntes Neighbor Advertisement Paket als Antwort. Was dann übrigens per Unicast passiert.
Da drin sind Ethernet Frame als Source und Destination MAC-Adressen die Adressen der beiden Stationen zwischen denen die Kommunikation stattfinden soll.
In unserem Fall sind dies als Quelle: 00-19-d1-b3-ea-d5 und als Ziel: CC-52-AF-CE-E5-49.
Im IP-Paket sind ebenfalls die Unicast Adressen der Interfaces enthalten.
Das eigentliche Neighbor Advertisement enthält dann noch einmal die eindeutige Zuordnung der MAC-Adresse zur IP-Adresse für welche dieses angefordert wurde.
Ich war jetzt schon sehr lange nicht mehr im Forum und muss mit entsetzen feststellen das Du Dich anscheinend immer noch gegen IPv6 sträubst.
Wenn Du das nicht willst Deine Sache. Aber Leute, die nicht mal auf den PI kommen erst noch was von nmap, arp(scan|ping), tcpdump erklären und wenn nötig erst noch installieren lassen, anstatt mal eben Boardtools, die auf jedem Rechner sind, zu nutzen. Also das verstehe ich nicht. Fehlt jetzt nur noch das Du schreibst: "aber das haben wir doch immer schon gemacht.", dann ziehen ich Dir noch nen Layer 3 durch Layer 7. 
Es ist der Ersatz, aber es wird nicht arp (Layer 2) sondern icmp6 (Layer 3) benutzt.
ARP wird "zwischen" Layer-2 und Layer-3 platziert (manche sagen auch Layer 2.5 ), um anzuzeigen, dass dieses Protokoll nur mit bestimmten Kombinationen von Layer-2- und Layer-3-Protokollen zusammenarbeitet. (ARP funktioniert meines Wissens nur mit der Kombination IPv4 und Ethernet).
Fritzbox
normales Netz: 192.168.178.xxx
Gastnetz: 192.168.179.xxx
Die Geräte im Gastnetz sieht man nicht in der Fritzbox.
Das würde voraussetzen das er GastLan aktiviert hat und den PI an Port 4 angeschlossen hat.
Und er hat geschrieben das es den PI auch anders verkabelt hat
Quote- andere Kabel, andere Anschüsse ebenfalls probiert
rkuepper:~# arp -a
? (10.0.2.1) at 78:8a:20:7:7a:95 on en0 ifscope [ethernet]
? (10.0.2.100) at c8:3c:85:47:5e:f7 on en0 ifscope [ethernet]
? (10.0.2.101) at b8:27:eb:8:7b:97 on en0 ifscope [ethernet]
? (10.0.2.103) at 8:66:98:d7:1b:2c on en0 ifscope [ethernet]
? (10.0.2.109) at c0:e8:62:91:94:69 on en0 ifscope [ethernet]
? (10.0.2.114) at 8c:85:90:c2:b1:ec on en0 ifscope permanent [ethernet]
? (10.0.2.118) at b0:70:2d:17:8f:d2 on en0 ifscope [ethernet]
? (10.0.2.119) at 78:ca:39:ff:ee:3c on en0 ifscope [ethernet]
all-systems.mcast.net (224.0.0.1) at 1:0:5e:0:0:1 on en0 ifscope permanent [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (225.255.255.255) at 1:0:5e:7f:ff:ff on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]
rkuepper:~# arp -a -d
10.0.2.1 (10.0.2.1) deleted
10.0.2.100 (10.0.2.100) deleted
10.0.2.101 (10.0.2.101) deleted
10.0.2.103 (10.0.2.103) deleted
10.0.2.109 (10.0.2.109) deleted
delete: cannot locate 10.0.2.114
10.0.2.118 (10.0.2.118) deleted
10.0.2.119 (10.0.2.119) deleted
224.0.0.1 (224.0.0.1) deleted
224.0.0.251 (224.0.0.251) deleted
225.255.255.255 (225.255.255.255) deleted
239.255.255.250 (239.255.255.250) deleted
rkuepper:~# ping6 -I en0 ff02::1
PING6(56=40+8+8 bytes) fe80::4cd:7514:2183:a952%en0 --> ff02::1
16 bytes from fe80::4cd:7514:2183:a952%en0, icmp_seq=0 hlim=255 time=0.099 ms
16 bytes from fe80::7944:59ac:146a:3544%en0, icmp_seq=0 hlim=64 time=4.293 ms
16 bytes from fe80::7a8a:20ff:fe07:7a95%en0, icmp_seq=0 hlim=64 time=4.588 ms
16 bytes from fe80::4e17:44ff:fe36:a0ec%en0, icmp_seq=0 hlim=255 time=9.228 ms
16 bytes from fe80::6a54:fdff:fe81:d598%en0, icmp_seq=0 hlim=255 time=13.106 ms
16 bytes from fe80::6a37:e9ff:fe54:8d3d%en0, icmp_seq=0 hlim=255 time=13.173 ms
16 bytes from fe80::4e17:44ff:fecf:d865%en0, icmp_seq=0 hlim=255 time=16.123 ms
16 bytes from fe80::48b:b273:298:321a%en0, icmp_seq=0 hlim=255 time=108.300 ms
16 bytes from fe80::4cd:7514:2183:a952%en0, icmp_seq=1 hlim=255 time=0.132 ms
16 bytes from fe80::7a8a:20ff:fe07:7a95%en0, icmp_seq=1 hlim=64 time=1.555 ms
16 bytes from fe80::7944:59ac:146a:3544%en0, icmp_seq=1 hlim=64 time=2.849 ms
16 bytes from fe80::48b:b273:298:321a%en0, icmp_seq=1 hlim=255 time=33.153 ms
16 bytes from fe80::4e17:44ff:fecf:d865%en0, icmp_seq=1 hlim=255 time=50.133 ms
16 bytes from fe80::4e17:44ff:fe36:a0ec%en0, icmp_seq=1 hlim=255 time=50.736 ms
16 bytes from fe80::6a54:fdff:fe81:d598%en0, icmp_seq=1 hlim=255 time=51.203 ms
16 bytes from fe80::6a37:e9ff:fe54:8d3d%en0, icmp_seq=1 hlim=255 time=51.342 msKlappt auch nach dem Arp Cache löschen.
Weil:
Neighbor Discovery Protocol (NDP) ist der Ersatz des Address Resolution Protocol (ARP) von IPv4 für IPv6. Es wird unter anderem dazu benutzt, IPv6-Adressen in Link-Layer-Adressen aufzulösen.
Also wer seine Geräte im Netzwerk vermisst und Local Link dazu hat kann bei,
Linux:
ip -6 neighMac oder BSD Systemen:
ndp -anWindows:
netsh interface ipv6 show neighbors level=verbosenach seinen Nachbarn im Netz fragen.
Du brauchst mit nicht mit Arp-Cache kommen wenn es dabei gar nicht gebraucht wird.
IPv6 hast Du ja explizit deaktivert und heutzutage ist das bei allen Geräten Gott sei dank local schon immer aktiv. Sehe auch keine Gründe IPv6 zu reaktiveren.
Arpping ok, aber er kennt ja nicht mal die IP von dem Ding. Er müsste ja auch erst einmal ein map machen.
Arpping und nmap ist nicht überall vorhanden. Nmap musste ich erst installieren und arpping müsste ich auch erst drauf machen.
nmap installieren und arpping installieren damit man dann erst gucken ob das Gerät online ist?
Da ist ein ping6 multicast schneller und selbst wenn der PI oder andere Geräte in einem komplett anderem Netz sind kommt man an sie ran.
Ja, aber es sollte doch kein Problem sein, sich mit dem Rechner im gleichen Netz zu befinden, oder?
Eigentlich nicht Aber dann würde er ja hier nicht fragen.
QuoteBTW: Nicht jeder benutzt IPv6 und der Ping (icmp) geht nicht, wenn der PI den Router bzw. den Rechner nicht in seinem arp-cache hat. Besser wäre dann ein arping (arp) statt ping (icmp), zum suchen/finden des PI.
Er hatte im ersten Post geschrieben das der PI neu ist und er ohne eingesteckt und eingeschaltet hat und schon nicht findet. Also wir der IPv6 nicht ausgeschaltet haben.
Bei IPv6 beruhen grundlegenden Mechanismen auf Neighbor Discovery Protocol (NDP) und Multicast. Der funktioniert das immer.
Ich konfiguriere keine Switche, Router, AccessPoints oder sonstige gerade mehr vorher an einem Rechner und gucke auch nicht nach welche Cisco, TP-Link, Speedport welche Standard Adresse hat.
Einstecken den ping6 und ab gehts. Wieso sollte ich meinen Rechner auch noch mit anderer bzw alias IP versehen wenn es auch so geht.
Der map bringt auch nur was wenn die Rechner im gleichem Netz sind oder Routing da hin klappen würde.
ping6 -I en0 ff02::1Schick den Ping mal ins Netz, dabei ist en0 ggf. anzupassen mit den Netzwerk Interface was Du am Rechner hast,
ping6 -I en0 ff02::1
PING6(56=40+8+8 bytes) fe80::4cd:7514:2183:a952%en0 --> ff02::1
16 bytes from fe80::4cd:7514:2183:a952%en0, icmp_seq=0 hlim=255 time=0.158 ms
16 bytes from fe80::7944:59ac:146a:3544%en0, icmp_seq=0 hlim=64 time=1.924 ms
16 bytes from fe80::7a8a:20ff:fe07:7a95%en0, icmp_seq=0 hlim=64 time=2.561 ms
16 bytes from fe80::6a54:fdff:fe81:d598%en0, icmp_seq=0 hlim=255 time=145.241 ms
16 bytes from fe80::6a37:e9ff:fe54:8d3d%en0, icmp_seq=0 hlim=255 time=145.430 ms
16 bytes from fe80::4e17:44ff:fe36:a0ec%en0, icmp_seq=0 hlim=255 time=146.921 ms
16 bytes from fe80::4e17:44ff:fecf:d865%en0, icmp_seq=0 hlim=255 time=147.793 ms
...Wenn die MacAdresse vom PI da auftaucht hast Du schon mal die richtige IPv6 LinkLocal Adresse und kannst damit den PI schon man ansprechen und wenn aktiv auch per SSH drauf. Wenn IPv6 privacy Zeug aktiv ist, dann ist die IPv6 != MacAddress. Dann hilft es den Pink laufen zu lassen und kurz Netzwerkkabel ziehen. Der Ping bekommt von allen Geräten im Netz Antwort, wenn Kabel gezogen wird sollte es einer weniger werden. In großen Netzwerken etwas schwieriger, aber bei den meisten Heimnetzen sollte man das so hinbekommen.
Drauf kommst Du dann per SSH so:
ssh -l pi fe80::7944:59ac:146a:3544%en0
The authenticity of host 'fe80::7944:59ac:146a:3544%en0 (fe80::7944:59ac:146a:3544%en0)' can't be established.
ECDSA key fingerprint is SHA256:P8VZjr0KSVWEdtzyxTcjk5INZa6DSdRfwX4tocUkGj8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'fe80::7944:59ac:146a:3544%en0' (ECDSA) to the list of known hosts.
pi@fe80::7944:59ac:146a:3544%en0's password:
Linux pi03 4.19.57-v7+ #1244 SMP Thu Jul 4 18:45:25 BST 2019 armv7l
Last login: Wed Aug 7 00:36:58 2019 from 172.18.8.254
pi@pi03:~ $ip -f inet a s dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 10.0.2.101/24 brd 10.0.2.255 scope global eth0
valid_lft forever preferred_lft foreverUn Du hast die IP von dem Teil. Oder kannst das fixen was kaputt ist.
cya
Rüdiger
Ja das geht
Moment. Was für Module muss er installieren können für Docker?
Quote from "djkobi" pid='299973' dateline='1505502423'
Dachte das ist nicht wirklich wichtig
Wir hatten mal mit unmanaged Switches in der Schule zutun, so ein managed Switch mit Weboberfläche klingt aber schon interessant, die Frage ist: Kann ich den auch dementsprechend konfigurieren wie einen unmanaged Switch, also VLANs selbst erstellen.... oder ist das nur so wie es in Amazon steht Plug & Play ?
Gruß
Ja du kannst natürlich da selbst VLANs anlegen.
Quote from "JLackxy" pid='299636' dateline='1505369779'
Da Dein Freunt Root-Rechte auf dem RaspberryPi hat, verbietet sich eine Lösung auf dem Pi selber.
Eine Lösungsmöglichkeit währe ein externer Radiusserver mit passendem Managed-Switch. Damit kann mam festlegen wer/wie Zugriff auf einzelne Netzwergeräte hat. Das ist aber keine billige Lösung.
Mit freundlichen Grüßen
JLacky
Managed Switch ja ok wäre eine Möglichkeit.
Aber wozu zusätzlich den Radius-Server?
Völlig unnötig. Vlans konfigurieren und fertig ist die Laube.
Und wenn es wirklich darum geht Vlans zuhaben gibt es schon kleine 4-8 Port Switche die das für wenig Geld können. Noch günstiger ist dann nur noch einen alten Linksys wr54 irgendwo abzustauben oder für 5€ jemanden abzukaufen und dann damit Vlans fahren. Mit openWRT/DD-WRT leicht umzusetzen.
Aber der Pro Tip wurde ja schon genannt. 30€ und schenke ihm einen eigenen.
Ein dyndns Anbieter und auf einen der Webserver zb dem Ubuntu Server die 2. Domain für den Windows Server als vhost eintragen Port 80/443 der die Domain per ReverseProxy von der Windows Büchse nach draußen pumpt.
Die 2. Domain bekommt kein A Record sondern einen CName Record auf die erste Domain.
Beide lösen so auf die IPv4 Adresse auf und können über Port 80 und 443 angesprochen werden und werden dann auf dem Linux Server getrennt und entsprechend verarbeitet.
Rsync + cron.
Oder Tools wie rsnapshot benutzen. Das legt inkrementelle Backups mit nur den Änderungen an und das auch noch mit hartlinks. Spart dann Speicherplatz.
iptables -t nat -A PREROUTING -i bridge-s ! proxy-box -p tcp --dport 80 -j DNAT --to Proxy-box:8080
iptables -t nat -A POSTROUTING -o bridge -s local-network -d proxy-box -j SNAT --to iptables-box
iptables -A FORWARD -s local-network -d proxy-box -i bridge -o bridge -p tcp --dport 8080 -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forwardProxy-Box, local-Network, iptables-Box entsprechend deiner Config und Netwerks ersetzen.
Der Rechner der per IP Tables das redirect auf einen transparenten Proxy macht muss aber auch als default gw eingetragen sein. Aber da du schreibst der ganze Traffic geht ja schon über den PI passt es ja schon.
Denk aber auch dran das du am Proxy selbst so keine Authentifizierung machen kannst wenn der Proxy als transparenter Proxy benutzt wird. Der Client bekommt dann nämlich die Benutzer Passwort Abfrage von einem Rechner präsentiert den er gar nicht angefragt hatte. Das passiert dann nämlich in einer neuen TCP Verbindung mit der IP des Proxys. Aber da der Client eine ganz andere Seite aufrufen wollte verwirft er die Auth Anfrage.
Dein VPN Client von draußen kommt zb mit der ip 10.10.10.3, über den VPN Server 10.10.10.1 und dein VPN Client im Homenetz hat die 10.10.10.2.
Damit dein PI mit der 192.168.178.2 jetzt zu 10.10.10.3 kommt geht er zur FB 192.168.178.1 weil default gw. Das kennt dann die Route zum Netz 10.10.10.0/X. Die Route in das 10er Netz ist dann über die FB wenn sie das VPN verbindet oder wenn der PI das VPN aufmacht ist sie das Gateway für das 10er Netz.
Die VU Box kennt nur die FB als Gateway. Schickt dann auch Pakete an eine 10er IP und das Routing schickt es dann ans VPN direkt oder in deine Fall dann an die 192.168.178.2, wo dann die weitere Route und ggf. benötigte Masquerading statt findet.
Ok das passt. Sehr wahrscheinlich kennt das VU WebIF, besser gesagt die Box die Rückroute nicht.
Entweder setzt du eine Route für die VPN Gegenstelle oder das VPN Netz mit Ziel den PI. Dann weiß die Box auch wohin sie die Pakete zurück senden muss.
Wenn du eine Fritzbox hast kannst du diese Route auch da setzen für die IP oder das Netz. Dann ist es an einer Stelle und funktioniert dann auch wenn sich die IP an der VU Box ändert oder andere Clients im Netzwerk mal do erreichbar sein sollen.
Könntest dir das ganze aber auch mit eine nginx und Proxy Backend machen.
Was sagt denn cat /proc/sys/net/ipv4/ip_forward ?
Ich würde das ganze mit Ajax machen. Die Seite Ansicht läd nie neu so das auch die ein Fehler wie Connection Timeout erscheint.
Den eigentlichen content lässt man dann per Ajax nachladen.
Kommt es dabei zu einem Fehler kann man die anfangen und in dem Fall einfach den Inhalt nicht ändern sondern so lassen wie er ist.
Alternativ die Seite per Curl auf dem PI ziehen in ein neues Verzeichnis und wenn Curl mit HTTP Code 200 die Seite ziehen kann anschließend auf das neue Verzeichnis linken. Wenn kein 200er dann alles so lasse.
