Probleme mit einem Miner hinter Lancom 1793VA

Forum zum Thema Firewall

Moderator: Lancom-Systems Moderatoren

thalternate
Beiträge: 86
Registriert: 08 Feb 2017, 22:48
Wohnort: Rhein-Main

Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von thalternate »

Hallo Zusammen,

ich habe ein Haupt-Netz hinter meinem Lancom, in dem ich arbeite. Alle "IoT"-Geräte sind in einem eigenen VLAN, mit eigener IP-Adressen-Range.
Eigentlich funktioniert alles genau wie ich es will. Ich kann vom Hauptnetz auf das IoT-Netz zugreifen, andersherum aber nicht.

Nun habe ich neuerdings einen Helium-Miner (RAK mntd Goldspot) im IoT-Netz hängen. Nachdem er "dort" als relayed angegeben war, half mir eine Portweiterleitung von TCP44158 auf die interne per BootP fest vergebene Adresse.

Leider bootet sich der Miner grob alle Stunde neu. Den Grund nannte mit der Support: Er hat oft sehr lange und oft keinen Zugang zu 8.8.8.8, den er pingt. Und dann startet sich das System als letzte Lösung neu.

Ich hatte mich gewundert, warum im GS-2326P+ Link down/up eine der häufigsten Warnungen waren.

Der Support sagt, es sei zu 100% eine Firewall/Router-Einstellung, weil "This is 100% a firewall /security setting issue. as soon as I pushed the miner traffic the connection was dropped".

Meldungen, die der Miner von sich gab, waren zB:

Code: Alles auswählen

Mar 30 22:28:41 Helium-Hotspot user.warn kernel: [ 1093.742062] ICMPv6: NA: [MAC-Addr.] advertised our address fe80::[so ähnlich wie Mac-adresse] on eth0!
und

Code: Alles auswählen

Mar 30 12:36:20 Helium-Hotspot user.warn kernel: [ 1552.452518] net_ratelimit: 663 callbacks suppressed
sowie

Code: Alles auswählen

19:10:15 Helium-Hotspot user.warn kernel: [14387.966216] [watchgorilla][-]: ICMP to google DNS fail. Saving data, then reboot.
Was mir auffällt ist, dass da scheinbar mit IPv6 gearbeitet wird. Was ich eigentlich (aktiv) überhaupt nicht nutze.
Ich habe – einfach mal zu testzwecken – die IPv6-Firewall ausgeschaltet. Aber das kann ja nicht richtig sein.
Der Support sagte, dass der Miner scheinbar keine Daten raus kriegt, als ob da eine Sicherheitseinstellung etwas hemmt.
Die einzige Einstellung, die mir dazu in den Sinn kam, war eine QoS-Einstellung, die den Traffic von IoT-Netz einschränkt in Bezug auf die Bandbreite, aber das habe ich jetzt auch seit der Miner aktiv ist erstmal deaktiviert.

Ich stehe im Moment auf dem Schlauch, warum der Miner angeblich nicht 8.8.8.8 pingen können sollte.
Und wo ich noch schauen kann, um dieses Problem zu beheben.

Hat hier zufällig jemand Erfahrungen dazu / Ideen?
Lancom: 1721+ VPN, 1781VA, 2×1793VA, 5×LW-600, GS-2326P+, L-322agn
AVM: 2×7580
Ubiquiti: 3×Switch-8-150W, Switch-8-60W
Zyxel: 3×Digitalisierungsbox LTE Backup
GrandDixence
Beiträge: 922
Registriert: 19 Aug 2014, 22:41

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von GrandDixence »

Entweder diesen "Helium-Miner" so umkonfigurieren, dass er kein ICMP-Polling (Ping-Test) auf den Google Public DNS-Server durchführt.
https://developers.google.com/speed/public-dns/

https://de.wikipedia.org/wiki/Ping_(Dat ... ertragung)

Oder in der Routing-Tabelle vom LANCOM-Router das Routing für die IPv4-Adresse 8.8.8.8 so umkonfigurieren, dass diese ICMP-Datenpakete (Ping) bei einem internen Netzwerkteilnehmer landen und von diesem beantwortet werden (Pong).

Oder eine Firewallregel konfigurieren, welche Pings vom Helium-Miner über den WAN-Anschluss an die IPv4-Adresse 8.8.8.8 durchlässt.

Aber die beste Lösung wäre sicher, sich von diesem "Helium-Miner" zu trennen. So ein Gerät ist doch reine Energieverschwendung!

Wenn kein IPv6 verwendet wird, sollte die Unterstützung von IPv6 im LANCOM-Router aus Sicherheitsgründen ausgeschaltet werden.

Welche Daten die Firewall des LANCOM-Routers durchlässt, kann man mit der Zustandstabelle der SPI-Firewall feststellen. Siehe dazu:
fragen-zum-thema-firewall-f15/firewall- ... ml#p109378
thalternate
Beiträge: 86
Registriert: 08 Feb 2017, 22:48
Wohnort: Rhein-Main

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von thalternate »

Vielen Dank für die – wie immer tolle und hilfreiche – Antwort.

Es ist ja ein Raspi, der ist mit seinen derzeit 3,4 W super sparsam.
IPv6 habe ich mal deaktiviert. Ich nutze es aktiv nicht zur Zeit.
Die Verbindungsliste zeigt einige Verbindungen, auch zu 8.8.8.8 – allerdings sagte mir das Log des Miners ja, dass es etliche Male nicht ging. Das kann ich hier jetzt nicht sehen.

Leider ist den Miner umzukonfigurieren keine Option, da ich darauf keinen Zugriff habe.

Ich werde das jetzt mal im Blick behalten und ggf. mal eine Regel zum durchlassen der Pings einrichten. Aber: Sollten die nicht sowieso durch dürfen? Ich habe keine Regel aktiv, die etwas verhindert.
Lancom: 1721+ VPN, 1781VA, 2×1793VA, 5×LW-600, GS-2326P+, L-322agn
AVM: 2×7580
Ubiquiti: 3×Switch-8-150W, Switch-8-60W
Zyxel: 3×Digitalisierungsbox LTE Backup
Dr.Einstein
Beiträge: 2481
Registriert: 12 Jan 2010, 14:10

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von Dr.Einstein »

Ist der Zeitraum für einen Absturz grob für dich einschätzbar? Also so jede Stunde / jeden Tag zur gleichen Zeit o.ö.?

Wenn ja, log dich mal via SSH auf deinen Lancom ein und mach

Code: Alles auswählen

trace # ip-r @ 8.8.8.8
und lass diesen Debug mal im Hintergrund laufen. Sorge auf jeden Fall dafür, dass dein Putty eine .txt Datei als Log schreibt. Sobald dir am Switch wieder ein Shutdown auffallen sollte, Trace stoppen (gleicher Befehl erneut / Pfeiltaste nach oben + Enter drücken).

Wenn du jetzt den Zeitpunkt des Ausfalls in der Log suchst, müsstest du ja theoretisch was sehen können. Entweder hat der Zeitraum plötzlich eine komplette Lücke (= am router kommt vom LAN nichts mehr an), du siehst Pakete (werden diese geblockt = filtered? Ursache), oder gehen sogar die ICMP Pakete weiterhin durch und werden beantwortet (= Clientseitiger Fehler? Switchfehler? ARP Problem?)

Ich denke, dein Fehler sollte sich mit diesem Mittel relativ leicht eingrenzen lassen.

Gruß Dr.Einstein
thalternate
Beiträge: 86
Registriert: 08 Feb 2017, 22:48
Wohnort: Rhein-Main

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von thalternate »

Oh, das habe ich jetzt mal getestet. War noch nie mit ssh auf dem Router.

Da kriege ich jetzt diese drei Meldungen im Wechsel, over and over:

Code: Alles auswählen

[IP-Router] 2022/03/31 20:40:04,265
IP-Router Rx (TELEKOM, RtgTag: 2):
DstIP: 192.168.0.20, SrcIP: 8.8.8.8, Len: 268, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 33584, SrcPort: 53
Route: LAN-1 Tx (IOT)

[IP-Router] 2022/03/31 20:40:04,968
IP-Router Rx (LAN-1, IOT, RtgTag: 2):
DstIP: 8.8.8.8, SrcIP: 192.168.0.20, Len: 61, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 53, SrcPort: 42807
Route: WAN Tx (TELEKOM)

[IP-Router] 2022/03/31 20:40:04,986
IP-Router Rx (TELEKOM, RtgTag: 2):
DstIP: 192.168.0.20, SrcIP: 8.8.8.8, Len: 173, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 42807, SrcPort: 53
Filter (limited)
Was sagt mir denn in der dritten Meldung das "Filter (limited)"? Hier wird die Frage zwar angerissen, es aber nicht geklärt.
Lancom: 1721+ VPN, 1781VA, 2×1793VA, 5×LW-600, GS-2326P+, L-322agn
AVM: 2×7580
Ubiquiti: 3×Switch-8-150W, Switch-8-60W
Zyxel: 3×Digitalisierungsbox LTE Backup
Dr.Einstein
Beiträge: 2481
Registriert: 12 Jan 2010, 14:10

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von Dr.Einstein »

Kannst du noch einmal auf ICMP filtern?

Code: Alles auswählen

trace # ip-r @ +"ICMP" +"192.168.x.y"
(IP austauschen gegen deinen Bitcoingenerator)

Dein Auszug zeigt aktuell nur DNS Anfragen. Laut deiner Beschreibung sollen es aber Pings sein. Wenn du nichts passendes, regelmäßiges ans Pings siehst, bleibe bei deinem ersten Trace, lass ihn laufen und analysiere die Ausfallzeit.

limited steht für Überbuchung des Anschlusses + das eine QoS Regel bevorzugt die verfügbare Übertragungsrate erhält. Dein Paket wird hinten angestellt / verworfen.

Gruß Dr.Einstein
plumpsack
Beiträge: 389
Registriert: 15 Feb 2018, 20:23

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von plumpsack »

@thalternate

Frage A)
Warum hängt dein "Miner" nicht direkt am 1793VA
Du schreibst selbst der hängt am GS-2326P+, also hinter dem 1793VA.

Frage B)
Du schreibst, du hast IPv6 deaktiviert.
Wo und wie?

Im 1793VA inkl. Routing

Zusätzlich in der Routing-Tabelle des Lancom-Routers wie z.B.:

Code: Alles auswählen

add  192.88.99.0      255.255.255.0    0        0               "0.0.0.0"              0         No          Yes      "block 192.88.99.0/24 Reserved - IPv6 to IPv4 relay"
(Beim Deaktivieren von IPv6 des GS-2326P+ bin ich raus, den kenn ich nicht.)

Beim Raspberry Pi via sysctl.conf ?
:G)
thalternate
Beiträge: 86
Registriert: 08 Feb 2017, 22:48
Wohnort: Rhein-Main

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von thalternate »

plumpsack hat geschrieben: 31 Mär 2022, 22:29 Warum hängt dein "Miner" nicht direkt am 1793VA
Du schreibst selbst der hängt am GS-2326P+, also hinter dem 1793VA.
1793 Keller (Nahe an DSL-Auslass), Miner EG (Nahe an Außenantennenanschluss). Plus ich möchte PoE nutzen.
plumpsack hat geschrieben: 31 Mär 2022, 22:29 Du schreibst, du hast IPv6 deaktiviert.
Wo und wie?
an zwei Stellen im 1793:
- ipv6 allgemein ipv6 aktiviert auf AUS.
- kommunikation protokolle ppp-liste ipv6 routing aktivieren auf AUS
plumpsack hat geschrieben: 31 Mär 2022, 22:29 (Beim Deaktivieren von IPv6 des GS-2326P+ bin ich raus, den kenn ich nicht.)
Da habe ich es an gelassen, weil es von da ja nicht weiter ginge.
plumpsack hat geschrieben: 31 Mär 2022, 22:29 Beim Raspberry Pi via sysctl.conf ?
da komme ich nicht rein. der helium miner ist nicht offen für mich.
Lancom: 1721+ VPN, 1781VA, 2×1793VA, 5×LW-600, GS-2326P+, L-322agn
AVM: 2×7580
Ubiquiti: 3×Switch-8-150W, Switch-8-60W
Zyxel: 3×Digitalisierungsbox LTE Backup
thalternate
Beiträge: 86
Registriert: 08 Feb 2017, 22:48
Wohnort: Rhein-Main

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von thalternate »

Dr.Einstein hat geschrieben: 31 Mär 2022, 21:27 Kannst du noch einmal auf ICMP filtern?

Code: Alles auswählen

trace # ip-r @ +"ICMP" +"192.168.x.y"
Läuft jetzt. Bisher noch kein reboot des Miners.
Trotzdem schon diese beiden Meldungen:

Code: Alles auswählen

[IP-Router] 2022/04/01 08:48:30,853
IP-Router Rx (LAN-1, IOT, RtgTag: 2):
DstIP: 1.1.1.1, SrcIP: 192.168.0.20, Len: 201, DSCP: CS6 (0x30), ECT: 0, CE: 0
Prot.: ICMP (1), port unreachable
embedded IP header:
DstIP: 192.168.0.20, SrcIP: 1.1.1.1, Len: 173, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 50089, SrcPort: 53

Route: WAN Tx (TELEKOM)

[IP-Router] 2022/04/01 08:56:22,418
IP-Router Rx (LAN-1, IOT, RtgTag: 2):
DstIP: 8.8.8.8, SrcIP: 192.168.0.20, Len: 201, DSCP: CS6 (0x30), ECT: 0, CE: 0
Prot.: ICMP (1), port unreachable
embedded IP header:
DstIP: 192.168.0.20, SrcIP: 8.8.8.8, Len: 173, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 37234, SrcPort: 53

Route: WAN Tx (TELEKOM)
1.1.1.1 ist einer der DNS, die ich im System eingetragen habe, weswegen der vielleicht genutzt wird für eine Auflösung.
8.8.8.8 habe ich definitiv nicht eingetragen. Ist das normal, dass ein Port unreachable da als Antwort kommt?

Nachtrag:
Gerade hatte sich der Miner wieder selbst rebootet. Angeblich schaut er immer 10 nach voller Stunde nach 8.8.8.8, und wenn er es nicht findet, bootet er neu. Es kam jetzt aber keine kaputte Anfrage im Trace auf. Die oben genannte (also rund 15 Minuten früher) ist die letzte. Der braucht ja keine 15 Minuten, um herunterzufahren und wieder hoch.


Noch eine Frage zu deiner Erklärung von "limited": Die Leitung ist total frei. 200/40 MBit/s – kein anderer Traffic. Warum sollte da was "hinten angestellt" werden?
Lancom: 1721+ VPN, 1781VA, 2×1793VA, 5×LW-600, GS-2326P+, L-322agn
AVM: 2×7580
Ubiquiti: 3×Switch-8-150W, Switch-8-60W
Zyxel: 3×Digitalisierungsbox LTE Backup
thalternate
Beiträge: 86
Registriert: 08 Feb 2017, 22:48
Wohnort: Rhein-Main

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von thalternate »

Es gibt vermutlich keine Einstellung (außer DMZ, was ich ja nicht will), ihm nach außen hin alles explizit zu erlauben? Dem Miner?
"Später", wenn das erstmal läuft, möchte ich dann wieder die Regel aktivieren, die dem IoT-Netz nur ein Gewissen Bandbreite gibt, das habe ich jetzt erst bis er läuft aus.
Lancom: 1721+ VPN, 1781VA, 2×1793VA, 5×LW-600, GS-2326P+, L-322agn
AVM: 2×7580
Ubiquiti: 3×Switch-8-150W, Switch-8-60W
Zyxel: 3×Digitalisierungsbox LTE Backup
backslash
Moderator
Moderator
Beiträge: 6736
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von backslash »

hi thalternate
Trotzdem schon diese beiden Meldungen:

Code: Alles auswählen

[IP-Router] 2022/04/01 08:48:30,853
IP-Router Rx (LAN-1, IOT, RtgTag: 2):
DstIP: 1.1.1.1, SrcIP: 192.168.0.20, Len: 201, DSCP: CS6 (0x30), ECT: 0, CE: 0
Prot.: ICMP (1), port unreachable
embedded IP header:
DstIP: 192.168.0.20, SrcIP: 1.1.1.1, Len: 173, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 50089, SrcPort: 53

Route: WAN Tx (TELEKOM)

[IP-Router] 2022/04/01 08:56:22,418
IP-Router Rx (LAN-1, IOT, RtgTag: 2):
DstIP: 8.8.8.8, SrcIP: 192.168.0.20, Len: 201, DSCP: CS6 (0x30), ECT: 0, CE: 0
Prot.: ICMP (1), port unreachable
Da hat dein Miner (192.168.0.20) offenbar DNS-Anfragen an 8.8.8.8 und 1.1.1.1 gestellt, will die Antworen aber gar nicht hören und schickt deshalb ein ICMP Port unreahable zurück.
Wenn der Minder über den Google-DNS den Namen seine Ping-Ziels auflösen will, dann aber die Antowrten verwirft, dann kann er auch nichts pingen...
Da liegt das Problem aber eher nicht im LANCOM sondern im Miner

Oder hast du ein Portforwarding für einen UDP-Port größer 16384 eingerichtet und nutzt nicht die aktuelle Firmware? Dann könntest du in das gleiche Problem rennen wie hier: fragen-zur-lancom-systems-routern-und-g ... 19349.html

Gruß
Backslash
thalternate
Beiträge: 86
Registriert: 08 Feb 2017, 22:48
Wohnort: Rhein-Main

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von thalternate »

Danke für diesen Gedanken.

Hmmm, es ist eine TCP-Weiterleitung eines Ports >30000.
Als Firmware ist die LCOS 10.50.0725 (RU6) drauf, die laut dem Thread reichen müsste. Eine neuere finde ich nicht.
Lancom: 1721+ VPN, 1781VA, 2×1793VA, 5×LW-600, GS-2326P+, L-322agn
AVM: 2×7580
Ubiquiti: 3×Switch-8-150W, Switch-8-60W
Zyxel: 3×Digitalisierungsbox LTE Backup
backslash
Moderator
Moderator
Beiträge: 6736
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von backslash »

Hi thalternate,

ja die RU6 reicht aus... der in dem Link beschreibene Bug sit seit der 10.50RU1 behoben...

dann bleibt nur, daß der Miner die DNS-Antworten verwirft... Und da in dem Trace überhaupt kein Ping auftaucht, dürfte die Aussage, daß der Miner pingt auch nicht stimmen...

Weist du denn wenigstens, welche Namen der Miner auflösen will? Das läßt sich mit einem auf die IP des Miners gefilterten Ethernet-Trace herausfinden...

Am Ende könntest du das LANCOM dazu bringen den Google-Server zu faken, indem du ihm die 8.8.8.8 und 1.1.1.1 als "Loopback"-Adressen verpasst (IPv4 -> Allgemein -> Loopback-Adressen) und den vom Miner angefragten Namen im DNS-Server das LANCOMs mit der IP des LANCOMs einträgst. Dann pingt der Miner immer ein erreichbares Ziel an...

Gruß
Bacckslash
thalternate
Beiträge: 86
Registriert: 08 Feb 2017, 22:48
Wohnort: Rhein-Main

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von thalternate »

afaik will der nichts auflösen, sondern – so die Info vom Support des Miners (der sich aber hart auf den Standpunkt stellt, dass das ein firewall/security-Problem im Router sein muss) – nur die 8.8.8.8 pingen, um zu sehen, ob das netz noch da ist, und wenn nicht zur Sicherheit einen reboot auszulösen.

Hmmm, wenn der WIRKLICH nichts auflösen will, dann könnte ich das mit den Loopback-Adressen ja einfach mal versuchen.
Nee, aber dann würde ja niemand mehr den 1.1.1.1 nutzen können. Das ist mein Haupt-DNS. Dann stelle ich es vielleicht nur für die 8.8.8.8 ein und hoffe, das kein anderes IoT-Gerät darauf angewiesen ist. Ich kann es ja über das Routing Tag scheinbar auf des IoT-Netz beschränken.

Nachtrag: In einem kurzen Trace habe ich jetzt schon 2 Adressen gefunden, die er auflösen will. Die Trage ich dann unter DNS / Allgemein / Stationsnamen ein? Manche Anfragen lieferten mehrere unterschiedliche A-Einträge zurück. So fein kann ich das da ja gar nicht eintragen (habe alleine schon kein A zur Hand).

Kann der DNS-Tunnel-Filter, den ich unter DNS / Filter/Aliasse habe, der an ist, ein Teil des Problems sein? Den habe ich nicht angemacht, das ist vermutlich eine Standardeinstellung so? Könnte das passen?

Das mit dem Loopback nehme ich mal wieder raus. erstens startete er sich jetzt um 12:10 Uhr wieder neu, zweitens habe ich da gerade kein so stimmiges Gefühl zu.

Ich habe jetzt aber einen Trace, der auf meinen Miner gefiltert ist. Soll ich die 8 EInträge, die dann auf 8.8.8.8 zeigen, mal hier einzeln reinkopieren, damit jemand™ daraus was lesen kann?

Kann ich ihn irgendwie – für eine limitierte Zeit – über DMZ o.ä. direkt ans Netz binden? Um zu schauen, dass es WIRKLICH nicht am Router liegt?
Lancom: 1721+ VPN, 1781VA, 2×1793VA, 5×LW-600, GS-2326P+, L-322agn
AVM: 2×7580
Ubiquiti: 3×Switch-8-150W, Switch-8-60W
Zyxel: 3×Digitalisierungsbox LTE Backup
backslash
Moderator
Moderator
Beiträge: 6736
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Probleme mit einem Miner hinter Lancom 1793VA

Beitrag von backslash »

H thalternate
afaik will der nichts auflösen, sondern – so die Info vom Support des Miners (der sich aber hart auf den Standpunkt stellt, dass das ein firewall/security-Problem im Router sein muss) – nur die 8.8.8.8 pingen, um zu sehen, ob das netz noch da ist, und wenn nicht zur Sicherheit einen reboot auszulösen.
nur hat dein Trace doch gezeigt, daß er *NICHTS* pingt, sondern DNS-Anfragen macht...
Nee, aber dann würde ja niemand mehr den 1.1.1.1 nutzen können. Das ist mein Haupt-DNS. Dann stelle ich es vielleicht nur für die 8.8.8.8 ein und hoffe, das kein anderes IoT-Gerät darauf angewiesen ist. Ich kann es ja über das Routing Tag scheinbar auf des IoT-Netz beschränken.
nun ja, du könntest dei IOT-Netz mit einem Routng-Tag versehen und die Looback-Adfressen auch, denn sieht nur das IOT-Netz das LANCOM als 8.8.8.8 bzw. 1.1.1.1
Nachtrag: In einem kurzen Trace habe ich jetzt schon 2 Adressen gefunden, die er auflösen will. Die Trage ich dann unter DNS / Allgemein / Stationsnamen ein?
ja...
Manche Anfragen lieferten mehrere unterschiedliche A-Einträge zurück. So fein kann ich das da ja gar nicht eintragen (habe alleine schon kein A zur Hand).
du solltest da die IP des LANCOMs eintragen, damit der Miner das LANCOM anping. Wenn das aber irgendwelche Adressen sind die der Miner sonst noch für seinen Betrieb braucht, dann bringt das nichts - außer deß der Miner dann garantieret nicht mehr funktioniert. Dann kannst du dir das mit den Looback-Adresen aber auch sparen..
Kann der DNS-Tunnel-Filter, den ich unter DNS / Filter/Aliasse habe, der an ist, ein Teil des Problems sein? Den habe ich nicht angemacht, das ist vermutlich eine Standardeinstellung so? Könnte das passen?
Der greift nur, wenn das LANCOM auch der DNS-Server ist... Da der Miner aber direkt mit dem Google-Server sprechen will, greifen sämtliche DNS-Eintellungen des LANCOMs nicht.
Ich habe jetzt aber einen Trace, der auf meinen Miner gefiltert ist. Soll ich die 8 EInträge, die dann auf 8.8.8.8 zeigen, mal hier einzeln reinkopieren, damit jemand™ daraus was lesen kann?
Kannst du gerne machen - die Frage ist nur, ob hier jemand ist, der daraus die richtigen Schlüsse ziehen kann.
Kann ich ihn irgendwie – für eine limitierte Zeit – über DMZ o.ä. direkt ans Netz binden? Um zu schauen, dass es WIRKLICH nicht am Router liegt?
eine DMZ ist auch nur ein ganz normales Netz (mit ein paar Besonderheiten bei der ARF-Sichtbarkeit und der Maskierungs-Option) - der Router bleibt immer noch dazwischen.

Laß den auf den (auf den Minder gefilterten) Router-Trace doch mal 10 Minten nach der vollen Stumne laufen, um zu shene, was da kommt, kurz bevor der Miner bootrt...
wie gesgt: bisher war in deinen Traces *KEIN* Ping des Miners zu sehen

Gruß
Backslash
Antworten

Zurück zu „Fragen zum Thema Firewall“