(IP-IP): connection refused

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

plumpsack
Beiträge: 569
Registriert: 15 Feb 2018, 20:23

(IP-IP): connection refused

Beitrag von plumpsack »

Was bedeutet das?

Nach dem "alten Schema" steht bei mir folgender Alarm:

Code: Alles auswählen

LOCAL3 	Alarm 	Dst: xxx.xxx.xxx.xxx {ROUTER}, Src: yyy.yyy.yyy.yyy (IP-IP): connection refused
Die Firmware ist immer noch, 10.50.1077, aktuell.

Danke schon einmal für die Info.
gzata
Beiträge: 43
Registriert: 26 Dez 2014, 18:09

Re: (IP-IP): connection refused

Beitrag von gzata »

plumpsack hat geschrieben: 03 Mär 2023, 21:24 Was bedeutet das?

Nach dem "alten Schema" steht bei mir folgender Alarm:

Code: Alles auswählen

LOCAL3 	Alarm 	Dst: xxx.xxx.xxx.xxx {ROUTER}, Src: yyy.yyy.yyy.yyy (IP-IP): connection refused
Die Firmware ist immer noch, 10.50.1077, aktuell.

Danke schon einmal für die Info.

Hallo und guten Abend

Wenn ich das auf dem FTP richtig sehe, ist Deine Version Beta
LANCOM-Beta/LCOS/LCOS 10.50/BUIL1077/

aktuelle Lancom Releases sind:

a) auf der 10.50er Schiene die 10.50.1107 RU10
(gem. Release Notes: "Wenn ein Netzwerk-Teilnehmer im lokalen Netzwerk des Routers eine DNS Anfrage zu schnell wiederholt, wird eine zweite DNS-Anfrage mit dem gleichen Quell-Port an den Backup-DNS-Server geschickt. Nach Erhalt der Antwort eines der beiden DNS-Server wird der Port geschlossen. Erhält der Router anschließend auch noch die Antwort des zweiten DNS-Servers, wird
diese abgelehnt.
Dadurch wurde die Meldung „connection refused“ im Syslog aufgezeichnet
(Priorität ‚Alarm‘). Durch dieses Verhalten konnte es vorkommen, dass im
Syslog viele ‚False Positive‘-Meldungen aufgezeichnet wurden. Die Priorität
der Meldung „connection refused“ wurde jetzt auf ‚Info‘ geändert, sodass
diese in der Standard-Konfiguration nicht im Syslog aufgezeichnet wird)"

b) auf der 10.70 Schiene die LCOS-10.72.0092 SU2
(gem. Release Notes: "→ „Connection Refused“-Meldungen werden nun im Syslog mit Level ‚Info‘ statt „Alarm“ angezeigt. Dies führt dazu, dass diese Meldungen nicht mehr im Syslog der WEBconfig im Default angezeigt werden.
Das Verhalten kann durch eine Konfigurationsänderung angepasst werden,")

Also vermutlich liegt es an der Beta Version -
.... und wenn ich mich recht erinnere ist das Thema schon in einem andern Thread ausführlich abgehandelt worden.

Viele Grüße


"
1781VA, WLC-Option, All-IP-Option, PublicSpot-Option
plumpsack
Beiträge: 569
Registriert: 15 Feb 2018, 20:23

Re: (IP-IP): connection refused

Beitrag von plumpsack »

gzata hat geschrieben: 03 Mär 2023, 22:43 Wenn ich das auf dem FTP richtig sehe, ist Deine Version Beta
LANCOM-Beta/LCOS/LCOS 10.50/BUIL1077/

aktuelle Lancom Releases sind:
A) Das sind keine "Beta-Versionen":

Code: Alles auswählen

https://ftp.lancom.de/T-Systems-Releases/LC-R883-plus/
LC-R883-plus-10.50.1077.upx

Code: Alles auswählen

https://ftp.lancom.de/T-Systems-Releases/LC-R883VAW/
LC-R883VAW-10.50.1077.upx

Code: Alles auswählen

https://ftp.lancom.de/T-Systems-Releases/LC-R884VA/
LC-R884VA-10.50.1077.upx

Und B)

Was bedeutet die Meldung IP-IP ?
gzata hat geschrieben: 03 Mär 2023, 22:43 .... und wenn ich mich recht erinnere ist das Thema schon in einem andern Thread ausführlich abgehandelt worden.
Wo steht was "(IP-IP): connection refused" bedeutet?

:evil:
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: (IP-IP): connection refused

Beitrag von backslash »

genau das ist dert Grund, weshalb das in der 10.72 auf Info herbgsetuft wurde.

Es wurde dir auch schon mehrfach erklärt!
Benutzeravatar
LoUiS
Site Admin
Site Admin
Beiträge: 5031
Registriert: 07 Nov 2004, 18:29
Wohnort: Aix la Chapelle

Re: (IP-IP): connection refused

Beitrag von LoUiS »

Ignorier den Troll doch einfach. Wenn Ihr Ihm auch noch antwortet kriegt er nur unnoetig Aufmerksamkeit.
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: (IP-IP): connection refused

Beitrag von tstimper »

Zurück zum eigentlichen technischen Sachverhalt
gzata hat geschrieben: 03 Mär 2023, 22:43 aktuelle Lancom Releases sind:

a) auf der 10.50er Schiene die 10.50.1107 RU10
(gem. Release Notes: "Wenn ein Netzwerk-Teilnehmer im lokalen Netzwerk des Routers eine DNS Anfrage zu schnell wiederholt, wird eine zweite DNS-Anfrage mit dem gleichen Quell-Port an den Backup-DNS-Server geschickt. Nach Erhalt der Antwort eines der beiden DNS-Server wird der Port geschlossen. Erhält der Router anschließend auch noch die Antwort des zweiten DNS-Servers, wird
diese abgelehnt.
Sind wir wirklich alle der Meinung, das hier das Verhalten von LCOS korrekt ist?
Also wenn ein Client " zu schnell" (was ist eigentlich "zu schnell", gibt es da einen Parameter, den man sehen oder setzen kann?)
die DNS Anfrage wiederholt, sollte da nicht zumindest dann,
wenn LCOS diese Anfrage an den im LCOS konfigurierten Backup DNS Server schickt, dem zuzusagen ausgehend ein anderer Quellport zugeordnet werden? Wie gesaht, die Anfrage geht ja auch noch an eine ganz anderer IP Adresse, also natürlich hat so eine Anfrage ein anderen Quellport zu haben.


Warum kann das nicht innerhalb LCOS geeignet behandelt werden?
gzata hat geschrieben: 03 Mär 2023, 22:43 Dadurch wurde die Meldung „connection refused“ im Syslog aufgezeichnet
(Priorität ‚Alarm‘). Durch dieses Verhalten konnte es vorkommen, dass im
Syslog viele ‚False Positive‘-Meldungen aufgezeichnet wurden. Die Priorität
der Meldung „connection refused“ wurde jetzt auf ‚Info‘ geändert, sodass
diese in der Standard-Konfiguration nicht im Syslog aufgezeichnet wird)"
Its es wirklich die richtige Vorgehensweise, den Syslog auf "Info" zusetzen,
um die Admins nicht zu nerven?

Dadurch geht ja die Sicht auf die „connection refused“ Meldungen, die ggf interessieren würden, verloren.

Ich hab mal kurz RFCs gegoogled

https://datatracker.ietf.org/doc/html/r ... ection-4.1

Code: Alles auswählen

The following address and port mapping behavior are defined:

      Endpoint-Independent Mapping:

         The NAT reuses the port mapping for subsequent packets sent
         from the same internal IP address and port (X:x) to any
         external IP address and port.  Specifically, X1':x1' equals
         X2':x2' for all values of Y2:y2.


Address-Dependent Mapping:

         The NAT reuses the port mapping for subsequent packets sent
         from the same internal IP address and port (X:x) to the same
         external IP address, regardless of the external port.
         Specifically, X1':x1' equals X2':x2' if and only if, Y2 equals
         Y1.

Address and Port-Dependent Mapping:

         The NAT reuses the port mapping for subsequent packets sent
         from the same internal IP address and port (X:x) to the same
         external IP address and port while the mapping is still active.
         Specifically, X1':x1' equals X2':x2' if and only if, Y2:y2
         equals Y1:y1.

REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior.
Also wenn ich das richtig verstehe:

Code: Alles auswählen

REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior.
MUSS LCOS (wenn es der RFC für NAT folgen will) für die zweite Anfrage, die es an den Backup DNS Server schickt, einen separaten Quellport öffnen
und auch die Antwort vom Backup DNS Server an den internen Client weiterleiten.

Es wäre also falsch, das durch Ändern des Loglevels für ALLE "connection refused" Meldungen von Alarm auf Info zu setzen.

Das könnte man allerhöchstens für diesen speziellen Fall machen, wo eine Anfrage kurz hintereinander an Primary und Backup DNS geschickt wird.

Richtiger wirds dadurch nicht.

Richtig wäre: es ist eine neue ausgegende Verbindung seitens LCOS aun eine neue IP Adresse, deshalb neuer Quellport und korrektes Weiterleiten der Antwort an den fragenden Client


Viele Grüße

ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: (IP-IP): connection refused

Beitrag von backslash »

Hi tstimper

Code: Alles auswählen

MUSS LCOS (wenn es der RFC für NAT folgen will) für die zweite Anfrage, die es an den Backup DNS Server schickt, einen separaten Quellport öffnen
und auch die Antwort vom Backup DNS Server an den internen Client weiterleiten.
Das DNS-Forwarding ist kein NAT...

Und daß der Port geschlossen wird, wenn eine Antwort kommt, dient dazu, DNS-Cache-Poisoning per DNS-Spoofing zu verhindern... siehe dazu auch https://www.heise.de/security/meldung/M ... 84975.html

Gruß
Backslash
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: (IP-IP): connection refused

Beitrag von tstimper »

backslash hat geschrieben: 06 Mär 2023, 18:46 Hi tstimper
Das DNS-Forwarding ist kein NAT...
ok, da LCOS von der Public IP aus den DNS Request sendet
backslash hat geschrieben: 06 Mär 2023, 18:46 Und daß der Port geschlossen wird, wenn eine Antwort kommt, dient dazu, DNS-Cache-Poisoning per DNS-Spoofing zu verhindern... siehe dazu auch https://www.heise.de/security/meldung/M ... 84975.html
Dss gild bei DNS Anfragen an DENSELBEN DNS Server, nicht für DNS Anfragen an VERSCHIEDENE DNS Server.

Viele Grüße

ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
gzata
Beiträge: 43
Registriert: 26 Dez 2014, 18:09

Re: (IP-IP): connection refused

Beitrag von gzata »

Guten Abend
backslash hat geschrieben: 06 Mär 2023, 18:46
Das DNS-Forwarding ist kein NAT...

Und daß der Port geschlossen wird, wenn eine Antwort kommt, dient dazu, DNS-Cache-Poisoning per DNS-Spoofing zu verhindern... siehe dazu auch https://www.heise.de/security/meldung/M ... 84975.html
Vielen Dank Backslash und tstimper für Eure Ausführungen und den Link (den Artikel kannte ich noch nicht).
von tstimper » Heute, 18:04

Zurück zum eigentlichen technischen Sachverhalt
- hier noch zum Sachverhalt (IP - IP) -

Nur interessehalber,
könnte es sich bei der Src um ein mobiles Endgerät handeln, und (IP-IP) als Hinweis auf ein fehlerhaftes Tunneling deuten?
(siehe auch IP in IP encapsulation, RFC 1853).

Vielleicht liege ich auch komplett falsch - insoweit bitte um Nachsicht, ich stecke da nicht so tief drin.

Viele Grüße
.
1781VA, WLC-Option, All-IP-Option, PublicSpot-Option
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: (IP-IP): connection refused

Beitrag von backslash »

Hi gzata
Nur interessehalber,
könnte es sich bei der Src um ein mobiles Endgerät handeln, und (IP-IP) als Hinweis auf ein fehlerhaftes Tunneling deuten?
(siehe auch IP in IP encapsulation, RFC 1853).
ja, in der Klammer steht das Protokoll - hier also IPv4-in-IP. Mehr ist da aber nicht rauszuholen... "connection refused" sagt halt nur, daß da ein Paket an die IP des LANCOMs gerichtet war, für das das LANCOM keinen Listener hat.

Gruß
Backslash
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: (IP-IP): connection refused

Beitrag von tstimper »

backslash hat geschrieben: 07 Mär 2023, 10:32 Hi gzata
Nur interessehalber,
könnte es sich bei der Src um ein mobiles Endgerät handeln, und (IP-IP) als Hinweis auf ein fehlerhaftes Tunneling deuten?
(siehe auch IP in IP encapsulation, RFC 1853).
ja, in der Klammer steht das Protokoll - hier also IPv4-in-IP. Mehr ist da aber nicht rauszuholen... "connection refused" sagt halt nur, daß da ein Paket an die IP des LANCOMs gerichtet war, für das das LANCOM keinen Listener hat.

Gruß
Backslash
Hi Backslash,

das erklärt gut die vermutete Implementation.

Bekommt LCOS eine DNS Anfrage von einem interen Client, schickt es die an den ersten konfiguriuerten oder per DHCP vom Provider übergebenen DNS Server und öffnete dazu einen Listener.

Bekommt LCOS "kurz dannach" (ist diese Zeit irgendwo spezifiziert?) eine weitere DNS Anfrage von demselben internen Client,
so schickt LCOS eine DNS Anfrage über an den Backup DNS Server und nutzt dafür denselben Listener, ohne im mitzuteilen, das er auf zwei
Antworten und auch noch von verschiedenen DNs Servern hören soll.

Kommt jetzt eine Antwort auf eine der beiden Anfragen, vermutlich egal von welchem DNS Server,
dann schliesst der Listener und die zweite Antwort wird verworfen.

Jetzt stellt sich natürlich folgende Frage:

Trackt LCOS überhaupt mit, von welchen beiden DNS Servern es in dem Moment eine Antwort erwartet?
Kann eigentlich nicht sein, denn das ist ja eine 1:1 Beziehung.

Daraus ergibt sich die zweite Frage, wie prüft LCOS in diesem Fall, ob die Antwort vom richtigen DNS Serevr kam?

Oder würde LCOS in diesem Fall (Listener ist offen für DNS UNABHÄNGIG von der sendenden IP?) auf JEDES DNS Reply auf dieses Listener Port antworten?

Also eigentlich sehe ich hier nur zwei Varianten, wie es implementiert sein könnte:

Variante 1: das Reply auf die DNS Anfrage auf den Backup DNS Server wird IMMER verworfen
Variante 2: es wird immer das erste Reply auf die DNS Anfrage weitergeleitet und alle weiteren Replies werden verworfen

Variante 2 kann aus meiner Sicht nur funktionieren, wenn dabei die Quell IP, also der DNS Server, der das Reply schickt, nicht geprüft wird.

Begründung: Der Listener hört auf einem Port auf eine Antwort von einer spezifischen IP, er kennt keine Liste von IPs und einen Zähler von Requests, auf die es Replies geben könnte.

Hier benötigen wir wirklich eine Klarstellung.

Variante 1 wäre ein Bug.
Variante 2 wäre eine CVE, da die Antwort IP nicht beprüft wird

Ich hoffe auf Variante 1 ...

Viele Grüße
ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: (IP-IP): connection refused

Beitrag von backslash »

Hi tsimper
Bekommt LCOS eine DNS Anfrage von einem interen Client, schickt es die an den ersten konfiguriuerten oder per DHCP vom Provider übergebenen DNS Server und öffnete dazu einen Listener.
korrekt
Bekommt LCOS "kurz dannach" (ist diese Zeit irgendwo spezifiziert?) eine weitere DNS Anfrage von demselben internen Client,
so schickt LCOS eine DNS Anfrage über an den Backup DNS Server und nutzt dafür denselben Listener, ohne im mitzuteilen, das er auf zwei
Antworten und auch noch von verschiedenen DNs Servern hören soll.
aber nur, wenn es auch eine Wiederholung ist, also, wenn der Client den Selben Quell-Port *UND* die selbe Transaction-ID verwednet - und der Listener weiss schin, daß es meherer Server gibt. Verlasse gedanklich bitte die Posix-Welt...
(ist diese Zeit irgendwo spezifiziert?)
das LANCOM wartet maximal 30 Sekunden auf eine Antwort, bevor der Listener definitiv wieder entfernt wird
Trackt LCOS überhaupt mit, von welchen beiden DNS Servern es in dem Moment eine Antwort erwartet?
Kann eigentlich nicht sein, denn das ist ja eine 1:1 Beziehung.
doch... Der Listener akzeptiert Antworten nur von den Serven, an die die Anfrage weitergeleitet wurde - und dann müssen natürlich in der Antwort auch Zielport und Transaction-ID sowie die DNS-Anfrage (Query) übereinstimmen.
Variante 1: das Reply auf die DNS Anfrage auf den Backup DNS Server wird IMMER verworfen
Variante 2: es wird immer das erste Reply auf die DNS Anfrage weitergeleitet und alle weiteren Replies werden verworfen
Variante 2
Variante 2 kann aus meiner Sicht nur funktionieren, wenn dabei die Quell IP, also der DNS Server, der das Reply schickt, nicht geprüft wird.
wie kommst du denn darauf?
Begründung: Der Listener hört auf einem Port auf eine Antwort von einer spezifischen IP, er kennt keine Liste von IPs und einen Zähler von Requests, auf die es Replies geben könnte.
Auf UDP-Ebene hört der Listener natürlich erstmal nur auf den Port... Sobald ein Paket ansteht, prüft er, ob es akzeptabel (Quell-IP, Quell-Port, Transaction-ID, Query) ist. Wenn nicht, kommt ein port unreachable zurück... Wenn es akzeptabel ist, wird der Listener geschlossen und das Paket an den Client im LAN weitergeleitet
Variante 2 wäre eine CVE, da die Antwort IP nicht beprüft wird
nein, denn die IP wird geprüft - und nich mehr...

Gruß
Backslash
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: (IP-IP): connection refused

Beitrag von tstimper »

backslash hat geschrieben: 07 Mär 2023, 16:40 Hi tsimper
Bekommt LCOS eine DNS Anfrage von einem interen Client, schickt es die an den ersten konfiguriuerten oder per DHCP vom Provider übergebenen DNS Server und öffnete dazu einen Listener.
korrekt
Bekommt LCOS "kurz dannach" (ist diese Zeit irgendwo spezifiziert?) eine weitere DNS Anfrage von demselben internen Client,
so schickt LCOS eine DNS Anfrage über an den Backup DNS Server und nutzt dafür denselben Listener, ohne im mitzuteilen, das er auf zwei
Antworten und auch noch von verschiedenen DNs Servern hören soll.
aber nur, wenn es auch eine Wiederholung ist, also, wenn der Client den Selben Quell-Port *UND* die selbe Transaction-ID verwednet - und der Listener weiss schin, daß es meherer Server gibt. Verlasse gedanklich bitte die Posix-Welt...
(ist diese Zeit irgendwo spezifiziert?)
das LANCOM wartet maximal 30 Sekunden auf eine Antwort, bevor der Listener definitiv wieder entfernt wird
Trackt LCOS überhaupt mit, von welchen beiden DNS Servern es in dem Moment eine Antwort erwartet?
Kann eigentlich nicht sein, denn das ist ja eine 1:1 Beziehung.
doch... Der Listener akzeptiert Antworten nur von den Serven, an die die Anfrage weitergeleitet wurde - und dann müssen natürlich in der Antwort auch Zielport und Transaction-ID sowie die DNS-Anfrage (Query) übereinstimmen.
Variante 1: das Reply auf die DNS Anfrage auf den Backup DNS Server wird IMMER verworfen
Variante 2: es wird immer das erste Reply auf die DNS Anfrage weitergeleitet und alle weiteren Replies werden verworfen
Variante 2
Variante 2 kann aus meiner Sicht nur funktionieren, wenn dabei die Quell IP, also der DNS Server, der das Reply schickt, nicht geprüft wird.
wie kommst du denn darauf?
Begründung: Der Listener hört auf einem Port auf eine Antwort von einer spezifischen IP, er kennt keine Liste von IPs und einen Zähler von Requests, auf die es Replies geben könnte.
Auf UDP-Ebene hört der Listener natürlich erstmal nur auf den Port... Sobald ein Paket ansteht, prüft er, ob es akzeptabel (Quell-IP, Quell-Port, Transaction-ID, Query) ist. Wenn nicht, kommt ein port unreachable zurück... Wenn es akzeptabel ist, wird der Listener geschlossen und das Paket an den Client im LAN weitergeleitet
Variante 2 wäre eine CVE, da die Antwort IP nicht beprüft wird
nein, denn die IP wird geprüft - und nich mehr...

Gruß
Backslash
Hi Backslash,

vielen Dank für die klare Erklärung.

Frage 1 : Wenn der Listener nun schon die Info hat, das die Anfrage an zwei verschiedene DNS Serevr geschickt wurde, weil es ja die Anfrage von Client zweimal gab, wenn auch mit derselben Transaktions Nummer, warum schickt LCOS dann die Anfrage nicht auch zweimal an den Client?
Ggf. weil die Transaktionsnummer gleich war und das als dieselbe Aktion betrachtet wurde? Kann eigentlich nicht sein, immerhin wird die DNS Anfrage an unterschiedliche DNS Server geschickt.

Frage 2 : Warum kommt es überhaupt dazu, das der Client den DNS Request mit demselben Quellport und derselben Transaktionsnummer mehrfach schickt?
Das frage ich deshalb, weil ich "gefühlt" lastabhängig genau solche DNS connection refused messages auf WLCs beobachte. Die kommen "aus heiterem Himmel" plötzlich vor und dann ist wieder eine Weile Ruhe.

Deswegen bin ich skeptisch, dieses Symtom mit Ändern des Loglevels zu behandeln, wenn vielleicht noch nicht klar ist, warum das denn wirklich passiert.

Nachdem, was ich beobachte, scheint das aufzutreten, wenn z.b. der WLC mit mehreren WLC Tunneln und / oder der LCOS Internet Router hohe CPU Last haben. Aber eindeutig ist es auch nicht.

Also was führt dazu, das der sendende Client der Meinung ist, das LCOS DNS Modul hat das Paket nicht empfangen und sendet mit derselben Transaktionsnummer nochmal. Zumal wenn wir ja z.B. beim Listenen 30 Sekunden Wartezeit auf Antworten haben.

Hast Du da Infos, welche Betriebssysteme / Geräte das betrifft?

Viele Grüße

ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: (IP-IP): connection refused

Beitrag von backslash »

Hi tstimper
Frage 1 : Wenn der Listener nun schon die Info hat, das die Anfrage an zwei verschiedene DNS Serevr geschickt wurde, weil es ja die Anfrage von Client zweimal gab, wenn auch mit derselben Transaktions Nummer, warum schickt LCOS dann die Anfrage nicht auch zweimal an den Client?
Ggf. weil die Transaktionsnummer gleich war und das als dieselbe Aktion betrachtet wurde? Kann eigentlich nicht sein, immerhin wird die DNS Anfrage an unterschiedliche DNS Server geschickt.
gleiche Quell-IP, gleicher Quell-Port, gleiche Trabnsaction-ID = gleiche Anfrage - darauf darf es nur eine Antwort geben, zur Vermeidung von DNS-Cache-Poisoning per DNS-Spoofing...
OK, wie sinnvoll das ist, und ob man nicht sowieso gleich auf DNSSec setzen sollte, steht auf einem ganz anderen Blatt...
Frage 2 : Warum kommt es überhaupt dazu, das der Client den DNS Request mit demselben Quellport und derselben Transaktionsnummer mehrfach schickt?
nomalerweise macht das ein Client nur, wenn der Server nicht geantwortet hat - so nach 1..2 Sekunden.
Das LANCOM nutzt diese Wiederholungen, um festzustellen, ob ein Server nicht funktioniert und schaltet bei einer Wiederholung auf den nächsten Server weiter. Nach 5 Minuten wird wieder der erste Server aktiv

Ich hab aber schon Clients gesehen, die die Wiederholung so schnell raushauen, daß kein Server eine Chance hatte zu antworten. Ein solch kaputter Client triggert dann genau die "connection refused" Meldung.

Und nein, ich habe keine Ahnung, warum die Clients das machen - es passiert halt...
Nachdem, was ich beobachte, scheint das aufzutreten, wenn z.b. der WLC mit mehreren WLC Tunneln und / oder der LCOS Internet Router hohe CPU Last haben. Aber eindeutig ist es auch nicht.
Eine hohe CPU-Last erhöht auch die Latenzen - aber daß die soweit erhöht werden, das es mehrere Sekunden duaert, kann ich mir eigentlich nicht vorstellen.
Obwohl: Man kann ein Gerät an einem langsamen Internetanschluß aus dem LAN natürlich so zuballern, daß sich tausende Pakete in der Sendequeue sammeln...

Gruß
Backslash
plumpsack
Beiträge: 569
Registriert: 15 Feb 2018, 20:23

Re: (IP-IP): connection refused

Beitrag von plumpsack »

LoUiS hat geschrieben: 06 Mär 2023, 12:15 Ignorier den Troll doch einfach. Wenn Ihr Ihm auch noch antwortet kriegt er nur unnoetig Aufmerksamkeit.
Hmm, wie soll ich Dich denn jetzt ansprechen wenn Du, als Admin hier im Forum, mich als Troll bezeichnest?
:G)

Ports wie u.A. UDP 389 sind dir bekannt?
:G)

Was soll das sein, wenn u.A. jemand von UDP Port :8 extern bei mir auf UDP Port :389 intern zugreifen will?

DNS-Fehler?
:G)
Antworten