Posts by matahari

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!
    Quote

    Meinst Du in der Ausgabe von "arp -a"? Ja, da muss es stehen.

    Genau, und solange das Problem nicht besteht habe ich da nur

    Code
    Address                  HWtype  HWaddress           Flags Mask            Iface
    192.168.101.84           ether   30:05:5c:79:e6:22   C                     eth0
    10.10.10.253             ether   00:50:b6:28:14:b6   C                     br0
    192.168.101.1            ether   c0:c9:e3:da:06:24   C                     eth0
    10.10.10.240             ether   00:50:b6:13:14:63   C                     br0

    Darum macht es in gewisser Weise sinn, dass das nichts im Dump erscheint...

    Da passiert leider nichts

    Code
    sudo tcpdump -c 30 -vvveni eth1 arp and host 8.8.8.8
    tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes

    hab´s mehrere Minuten laufen lassen...

    Code
    0 packets captured
    0 packets received by filter
    0 packets dropped by kernel
    Quote

    Evtl. kannst Du dann den time-sleep (jetzt 60 Sekunden) in deinem Script, um einiges reduzieren (z. B. auf 15 Sekunden).

    Das wäre vernachlässigbar. Es werden Telemetriedaten übertragen, wenn da mal eine Zeit lang nichts kommt ist es kein Problem - die Geräte speichern zwischen. Es geht tatsächlich nur darum, dass der Tunnel und die angeschlossenen Geräte vollkommen ohne Wartung auskommen sollen und müssen. Bedeutet, Fehler müssen selbstständig erkannt und gelöst werden. So starten sich die Geräte z.B. selbst neu wenn eine definierte Zeit lang das andere Tunnelende nicht gesehen wird.

    Quote

    in der /etc/sysctl.conf.

    Hat dein Switch eine MAC-Adresse?

    Meiner hätte schon eine, aber da wo das Ding nachher hängt habe ich keinen Einfluss auf irgendetwas an eth0. Nur das Gerät an eth1 ist von mir beeinflusst. Aktuell ist an dem Standort eine Fritzbox. Theoretisch könnte es mir wurscht sein, aber im Zweifel blockiere ich mir auch die Namensauflösung -das wäre blöd. Die Fritzboxen aktualisieren sich heutzutage automatisch, darauf folgt ein Neustart - und dann ist eth0 für mich down.


    Wenn ich am Timeout etwas ändere würde ja trotzdem das Problem bestehen bleiben, dass der erst anläuft wenn kein Verkehr mehr in die Richtung geht. Das Problem würde sich also nur zufällig eventuell lösen, eben dann wenn der Verkehr stoppt. Wobei die grundsätzliche Funktion gewährleistet ist sobald der Tunnel steht und ich über eth1 an die andere Seite komme - und das geht. Ist also mehr ein "nice to have". Darum meine Python-Lösung...

    Ich würde jetzt in Ermangelung einer besseren Idee folgendes Script mitstarten lassen:

    Das wird es wohl tun, aber ob das der sauberste Weg ist...

    Naja, vor dem Trennen taucht im arp ja nichts davon auf. Genaugenommen ist davor kein Eintrag zu eth1. Danach ist da eine ganze Reihe, alle incomplete.


    Löschen kann ich die incomplete-Einträge nicht...

    Code
    sudo arp -d 8.8.8.8
    SIOCDARP(dontpub): Network is unreachable

    Okay, ich habe jetzt testweise

    Code
    arp -a
    ? (10.10.10.240) at 00:50:b6:13:14:63 [ether] on br0
    ? (192.168.101.118) at c8:60:00:6e:51:f1 [ether] PERM on eth0
    ? (192.168.101.1) at c0:c9:e3:da:06:24 [ether] PERM on eth0
    ? (10.10.10.253) at 00:50:b6:28:14:b6 [ether] on br0
    ? (192.168.101.84) at 30:05:5c:79:e6:22 [ether] on eth0
    ? (192.168.101.65) at e4:5f:01:71:af:bb [ether] PERM on eth0

    eingestellt, dann ist mir aber etwas sehr kurioses aufgefallen. Ich habe vom Client an eth1 aus einen Ping zu google geschickt um zu sehen ob es noch geht.

    Soweit so klar. Jetzt hatte ich den Teamviewer noch auf und habe getrennt. Ok, nach dem erneuten Verbinden war der Ping weg - aber der Teamviewer ging wieder... Ein tracert zu 8.8.8.8 läuft nach der ip-Adresse des Pi´s an eth1 ins leere. Verwirrt habe ich einen anderen Host genommen - ohne Probleme. Und jetzt kommt´s. Die 8.8.8.8, die ich anpinge während ich die Verbindung vom Pi zum Internet trenne, ist nach dem Verbinden weg. Pinge ich eine andere Adresse, z.b. die 8.8.4.4 geht es aber. Und jetzt wird es richtig lustig. Wenn ich beim Trennen der Verbindung keinen Dauerping laufen lasse geht nach dem Verbinden alles wie gewohnt. Der Fehler tritt also, anders als ich erst fälschlicherweise erwartet habe, nur auf, wenn während des Trennens Datenverkehr fließt.


    Ping ich die 8.8.8.8 und trenne / verbinde ist die 8.8.8.8 nicht mehr erreichbar, die 8.8.4.4 schon

    Ping ich die 8.8..4.4 und trenne / verbinde ist die 8.8.8.8 erreichbar, die 8.8.4.4 nicht mehr


    Noch kurioser. Lasse ich den Ping durchlaufen bleibt der Host unerreichbar. Mache ich den Ping aus und warte einen Augenblick, vielleicht 1 oder 2 Minuten, dann geht der Ping wieder durch. In der Zeit darf aber kein Paket in den Host gegangen sein, sonst bleibt er unerreichbar. Zum Test habe ich ein einem Batch abwechselnd die 8.8.8.8 und den localhost gepingt um eine kurze Pause zu haben. Das funktionierte nicht.

    Dann habe ich gemessen wie lange die "Ruhe" dauern muss. Nach etwas rumprobieren habe ich einen konsistenten Wert gefunden.


    Wenn beim Trennen eine Verbindung bestand dann muss nach dem Wiederverbinden eine Pause von 30 Sekunden eingehalten werden. Sobald 30 Sekunden lang kein Paket an den spezifischen Host ging ist die Verbindung wieder möglich.


    Verrückt - aber ein Ansatz. Was hält 30 Sekunden lang seine Daten. Wird da etwas gecacht? Könnte ich alternativ im up-Script vom OpenVPN die eth1 Schnittstelle kurzfristig trennen. Ich habe es jetzt probiert mit ip link set eth1 down und 30 Sekunden später ip link set eth1 up. Das funktioniert soweit auch. Ich weiß nur nicht wie ich ihm das in !bash sagen könnte...

    Falls übrigens die Frage aufkommt warum denn wohl der Teamviewer danach geht - ich glaube die machen Round Robin.

    Beim PC an eth1 ändert sich nichts, da habe ich jedes mal

    Code
    Schnittstelle: 10.10.10.240 --- 0xf
      Internetadresse       Physische Adresse     Typ
      10.10.10.252          00-50-b6-28-0f-1b     dynamisch
      10.10.10.253          00-50-b6-28-14-b6     dynamisch
      10.255.255.255        ff-ff-ff-ff-ff-ff     statisch
      224.0.0.22            01-00-5e-00-00-16     statisch
      224.0.0.251           01-00-5e-00-00-fb     statisch
      224.0.0.252           01-00-5e-00-00-fc     statisch
      239.255.102.18        01-00-5e-7f-66-12     statisch
      239.255.255.250       01-00-5e-7f-ff-fa     statisch

    Am raspberry ändert sich sehr viel. Vor dem trennen, also nach dem Neustart habe ich da

    Code
    arp -a
    ? (192.168.101.1) at c0:c9:e3:da:06:24 [ether] on eth0
    ? (192.168.101.118) at c8:60:00:6e:51:f1 [ether] on eth0
    ? (192.168.101.84) at 30:05:5c:79:e6:22 [ether] on eth0
    ? (10.10.10.240) at 00:50:b6:13:14:63 [ether] on br0
    ? (10.10.10.253) at 00:50:b6:28:14:b6 [ether] on br0

    Nach dem Trennen, also wenn der Client an eth1 nicht mehr kann hingegen

    Ich pinge an dem Client google und habe den teamviewer auf

    Hallo nochmal,


    nachdem mein erstes Problemchen nun aus der Welt ist würde ich die ganze Sache gerne noch ein wenig verfeinern, aber irgendwie habe ich gerade einen Denkfehler.


    Ich habe einen VPN-Tunnel als Bridge. Durch diesen Tunnel soll nur das 10er Netz, kein anderes. Der Pi soll von seiner Schnittstelle eth0 direkt ins Internet kommen, die Clients im 10er Netz sollen über eth1 am Pi durchgereicht werden und letztendlich auch über eth0 ins Internet.


    Der Pi selbst kann es bereits, dafür habe ich in der openVPN-Konfiguration

    Code
    route-nopull
    route 10.10.10.0 255.255.255.0

    eingefügt.

    Den Clients an eth1 habe ich die 10er Adresse des Raspberrys als Default Gateway mitgegeben. Alleine bringt das schonmal nichts.

    Damit der Client ins Netz kommt habe ich am Pi

    Code
    sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

    dazugegben. Auch das funktioniert grundsätzlich. Aber während ich das so ausprobiert habe ist mir eine Sache aufgefallen.


    Situation: Ich habe einen Computer an eth1 des OpenVPN-Clients. eth0 des openVPN-Clients hängt über einen Switch am Internet.

    Der Computer kann durch den Tunnel und ins Internet pingen. Tracert geprüft, alles geht den korrekten weg.

    Tunnel ab- und aufbauen macht kein Problem.

    Trenne ich das Kabel vom Internet zum Switch bricht natürlich der Tunnel als auch die Pings sofort zusammen. Stecke ich das Kabel wieder baut es sich aber auch sofort wieder auf. Alles fein. Trenne ich aber das Kabel zwischen eth0 und Switch wird nach dem erneuten Verbinden zwar der Tunnel wieder aufgebaut, der Ping durch den Tunnel geht auch - der Ping vom Computer an eth1 ins Internet läuft dann aber ins leere. Der Pi kann ins Internet pingen. Starte ich den Pi neu ist wieder alles ok.


    Es passiert also irgendetwas wenn eth0 down geht. Hat da jemand eine Idee wonach ich da schauen muss?


    Danke!

    Matze

    Die werden nie heruntergefahren, die kommen an ihren Platz und laufen dann hoffentlich wieder ein paar Jahre durch. Also absichtlich werden sie nicht hart ausgeschaltet, aber über die Jahre hinweg passiert es doch ab und an das der Strom weg ist. In den letzten 5 Jahren musste ich 2 mal nach Stromausfällen die Karten tauschen...

    Genau. Ich habe jetzt erstmal wieder ruhe. Ich hoffe, dass das Overlay-Filesystem und die RO-Boot-Geschichte den Kasten unanfälliger machen. Ich liege doch richtig - mit den beiden Sachen aktiviert kann man den Pi einfach vom Strom nehmen ohne Rücksicht auf Verluste, oder?

    ip a kommt ;)


    Server

    Client

    Das Script habe ich hier gefunden. Tatsächlich vollkommen zufällig. Dieses zufällige war 2015 bei der letzten Installation allerdings auch das Problem. Irgendwann findet man die richtige Anleitung - das beinhaltet nicht das Verstehen dieser. Ich sehe in der ersten Zeile technisch eigentlich gar keinen Unterschied - aber ganz offensichtlich macht es einen ;)

    Nachdem ich jetzt beide Seiten auf Buster aktualisiert habe ist der Tunnel wieder tot. Auf Stretch ging es, hilft mit für den RP4 ja aber leider nicht.

    Allerdings war die Arbeit nicht umsonst - denke ich. Denn die Fehlermeldung ist identisch mit der, die ich bei der frisch installierten Version hatte.

    Code
    Wed Nov 24 23:12:16 2021 us=125638 client1/192.168.101.105:42100 MULTI: Learn: 9e:24:c4:51:52:9a -> client1/192.168.101.105:42100
    Wed Nov 24 23:12:17 2021 us=127699 client1/192.168.101.105:42100 MULTI: Outgoing TUN queue full, dropped packet len=86
    RWed Nov 24 23:12:18 2021 us=130028 client1/192.168.101.105:42100 MULTI: Outgoing TUN queue full, dropped packet len=90

    Ich finde zu dieser Meldung nicht viel, aber ich denke genau da müsste man ansetzen. Was soll das sein und wie kann ich das ändern. Ist die "TUN queue" irgendein Systemwert, gehört das zu openVPN oder zu Linux. Ich bin mir sicher, dass der Rest ohne Probleme läuft, wenn dieser Fehler behoben ist. Nur wie...


    Nachtrag:

    Der "Fehler" ist gefunden. Es lag am up-Script. Ich habe bei der Suche nach dem Fehler eines gefunden das nicht dem meinen entsprach. Ich habe also

    Bash
    #!/bin/bash
    brctl addif br0 tap0

    ersetzt durch

    Bash
    #!/bin/bash
    brctl addif br0 $1
    ifconfig $1 up

    Und der Spuk ist vorbei.


    Jetzt muss ich nur noch zusehen, das ich die ganzen anderen Änderungen rückgängig gemacht bekomme - aber der Ping geht jetzt


    Nachtrag 2:

    Nachdem ich die "frische Installation" wieder in den Ursprungszustand gebracht und dort ebenfalls das up-Script verändert habe laufen die RP4er auch so wie sie sollen.


    Vielen Dank, besonders an rpi444!

    Ok, ich habe an den alten jetzt allerdings keine Netzwerkkarte dran. Die steckt verschraubt im Gehäuse mit den RP4ern. Aber das sollte auch nichts zur Sache tun - der Server soll ja den Client erreichen und andersrum...


    Server alt

    Server neu



    Client alt

    Client neu