Posts by ruedigerp

  • Probleme VPN

    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.

  • Hilfe - raspberry taucht nicht im Netzwerk auf ...

    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. ;)

  • Hilfe - raspberry taucht nicht im Netzwerk auf ...

    Klappt 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:

    Code
    ip -6 neigh

    Mac oder BSD Systemen:

    Code
    ndp -an

    Windows:

    Code
    netsh interface ipv6 show neighbors level=verbose

    nach seinen Nachbarn im Netz fragen.

    Du brauchst mit nicht mit Arp-Cache kommen wenn es dabei gar nicht gebraucht wird.

  • Hilfe - raspberry taucht nicht im Netzwerk auf ...

    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.

    Display Spoiler

    sudo arping -c 3 -I en0 192.168.178.43

    sudo: arping: command not found

    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.

  • Hilfe - raspberry taucht nicht im Netzwerk auf ...

    Quote from rpi444

    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.

    Quote

    BTW: 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.

  • Hilfe - raspberry taucht nicht im Netzwerk auf ...

    Der map bringt auch nur was wenn die Rechner im gleichem Netz sind oder Routing da hin klappen würde.

    Code
    ping6 -I en0 ff02::1

    Schick den Ping mal ins Netz, dabei ist en0 ggf. anzupassen mit den Netzwerk Interface was Du am Rechner hast,

    Code
    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:

    Un Du hast die IP von dem Teil. Oder kannst das fixen was kaputt ist.

    cya

    Rüdiger

  • Pi vom LAN abschirmen

    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.

  • Pi vom LAN abschirmen

    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.

  • Auflösung mehrerer DynDNS

    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.

  • Gesamten Netzwerkverkehr auf Proxy umleiten

    Code
    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_forward

    Proxy-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.

  • VPN Gateway iptables ports öffnen transcoding

    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.

  • VPN Gateway iptables ports öffnen transcoding

    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.

  • Automatischer Cache-Zugriff des Browsers

    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.