DNS-Resolving im Tunneldigger-Client

Technik Gluon
1

Moin,

vielleicht weiß das ja jemand, so ganz steige ich durch l2tp_client.c noch nicht durch: unter welchen Umständen re-resolved der TD-Client auf den Knoten die FQDNs der Brokeradressen?

          if (connect(ctx->fd, result->ai_addr, result->ai_addrlen) < 0) {
            syslog(LOG_ERR, "[%s:%s] Failed to connect to remote endpoint - check WAN connectivity!",
              ctx->broker_hostname, ctx->broker_port);
            ctx->state = STATE_REINIT;

scheint mr dafür zu sorgen, daß in context_reinitialize() per

  if (ctx->broker_resq)
    asyncns_cancel(asyncns_context, ctx->broker_resq);
  ctx->broker_resq = NULL;
  ctx->usage = -1;

die DNS-Information genullt wird und neu aufgelöst?

Das deckt sich leider nicht mit der Beobachtung; gefühlt scheint die IP(v4)-Adresse einmal beim Start aufgelöst zu werden, dann aber „mindestens lange“ nicht mehr?

2 „Gefällt mir“
2

Ich glaub, das hab ich auch schon mehrfach erlebt ohne genau zu verstehen, was eigentlich klemmt.

1 „Gefällt mir“
3

Ich wollte GWs auf neue, standortspezifische v4-Adressen ziehen (193.x.x.x ⇒ 194.y.y.y), aber es kam einerseits keine einzige Verbindung zustande (über 24h trotz TTL 3600), dafür blieben manche Knoten aber auch gleich ganz Offline. Irgendwie scheint das mit dem Aktualisieren der Daten aus dem DNS und auch dem Wiederaufnehmen von Verbindungen nicht so zu tun, wie zumindest ich das erwartete.

Fragt sich, ob man in den Legacy-IP-only-Gaul noch Zeit investieren sollte, oder gleich auf ffmuc-mesh-vpn-wireguard-vxlan umsatteln …

4

dieses „Tunneldigger bekommt WAN-Networkänderungen nicht mit“ war einer Gründe, bei uns den Weekly-Reboot einzuführen.
Und da das immernoch ziemlich lang ist, wir aber auch nicht täglich rebooten wollen (und selbst das noch blöd lang wäre) haben wir ein Script zum Erkennen von unplausiblen Topologieänderungen (also z.B. "einen vpn-Link mit mehr als nur einem Knoten dahinter verschwindet dauerhaft-> reboot)
Knoten booten dann zwar häufiger auch mal „false positive“, aber immerhin kommen sie damit ins Netz zurück.

(Hilft jetzt bei dem konkreten Problem nicht. Beobachtet haben wir es aber auch gelegentlich und keinen Reim drauf machen können)

1 „Gefällt mir“
5

»Nebenan« rebootet man täglich, dürfte der Grund sein, warum die Kollegen mit Netzänderungen weniger Probleme haben.

Zwischenfazit: ich halluziniere mir »Dinge« mit Tunneldigger und DNS nicht zusammen, oder falls doch, dann zumindest nicht alleine. Schön. Nicht.

Hrmpft. Wieso macht man das alles eigentlich so kompliziert, asynchrone DNS-Abfragen (die zudem ein dokumentiertes Memoryleak mit sich bringen), WTF‽ Schleife abarbeiten, aktuelle IP-Adresse(n) aus dem DNS ziehen, connect() und weiter im Programm — oder wollte wer Tunneldigger im SubSecondTrading einsetzen?

6

Das Problem ist, wenn man (ich) noch weniger debuggen kann als Du das mit dem Intialposting getan hast. Wir haben halt nur festgestellt nach wem wechsel auf den Tunneldigger, dass zwar viele fastd-probleme weg waren, aber neue Dinge (regressions) dazugekommen sind.

Ich empfehle natürlich nicht, mit solchen hotfix-workarounds zu arbeiten, wenn die Möglichkeit zu qualifizierten Bugreports besteht. Hier ab er leider keine Löffel vorhanden für.

7

Naja, C ist jetzt nicht so das grundlegende Problem, bin ich alt genug für :wink:

Komplex daran ist, den geänderten Code in Openwrt/Gluon integriert zu bekommen — vorzugsweise ohne (weitere) Eingriffe in den Basiscode. Das ist definitiv nicht meine Welt. Scheint aber geklappt zu haben:

Jetzt noch ein paar weitere syslog() im Code verlieren, dann wird hoffentlich klarer, was der Code macht — und z. B. warum nur 2 der 4 konfigurierten GWs/Broker überhaupt kontaktiert wurden …

8

Okay, falls jemand mit auf die wilde Geisterjagd gehen möchte (mit Gluon 2018/2019; not tested for 2020 yet), der sage Bescheid:

root@33332-Schalueckstr-107-11d9:~# logread | grep td-
Wed Jul 20 02:41:49 2022 daemon.info td-client: Performing broker selection...
Wed Jul 20 02:41:49 2022 daemon.info td-client: Configured brokers: 4
Wed Jul 20 02:41:49 2022 daemon.info td-client: [g01m01.4830.org:10001] Trying broker ...
Wed Jul 20 02:41:49 2022 daemon.info td-client: [g02m01.4830.org:10001] Trying broker ...
Wed Jul 20 02:41:49 2022 daemon.info td-client: [g03m01.4830.org:10001] Trying broker ...
Wed Jul 20 02:41:49 2022 daemon.info td-client: [g04m01.4830.org:10001] Trying broker ...
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g01m01.4830.org:10001] Broker's IP hasn't been resolved yet.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g02m01.4830.org:10001] Broker's IP hasn't been resolved yet.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker's IP hasn't been resolved yet.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker's IP hasn't been resolved yet.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g02m01.4830.org:10001] Connected to remote endpoint at 193.26.120.227.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g02m01.4830.org:10001] Broker is in STATE_GET_USAGE, send initial request.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g01m01.4830.org:10001] Connected to remote endpoint at 193.26.120.99.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g01m01.4830.org:10001] Broker is in STATE_GET_USAGE, send initial request.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g03m01.4830.org:10001] Connected to remote endpoint at 193.26.120.125.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_GET_USAGE, send initial request.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g04m01.4830.org:10001] Connected to remote endpoint at 193.26.120.245.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_GET_USAGE, send initial request.
Wed Jul 20 02:41:50 2022 daemon.debug td-client: [g03m01.4830.org:10001] Broker usage: 3779
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:50 2022 daemon.debug td-client: [g04m01.4830.org:10001] Broker usage: 4164
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:50 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:51 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:51 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:52 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:52 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:53 2022 daemon.info td-client: [g01m01.4830.org:10001] Broker is in STATE_GET_USAGE, get cookie.
Wed Jul 20 02:41:53 2022 daemon.info td-client: [g02m01.4830.org:10001] Broker is in STATE_GET_USAGE, get cookie.
Wed Jul 20 02:41:53 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:53 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:53 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:53 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:53 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:53 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:54 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:54 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:55 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:55 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:56 2022 daemon.info td-client: [g01m01.4830.org:10001] Broker is in STATE_GET_USAGE, get cookie.
Wed Jul 20 02:41:56 2022 daemon.info td-client: [g02m01.4830.org:10001] Broker is in STATE_GET_USAGE, get cookie.
Wed Jul 20 02:41:56 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:56 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:56 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:56 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:56 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:56 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:57 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:57 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:58 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:58 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:59 2022 daemon.info td-client: [g01m01.4830.org:10001] Broker is in STATE_GET_USAGE, get cookie.
Wed Jul 20 02:41:59 2022 daemon.info td-client: [g02m01.4830.org:10001] Broker is in STATE_GET_USAGE, get cookie.
Wed Jul 20 02:41:59 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:59 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:59 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:59 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:59 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:41:59 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:42:00 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:42:00 2022 daemon.info td-client: [g04m01.4830.org:10001] Broker is in STATE_STANDBY.
Wed Jul 20 02:42:00 2022 daemon.info td-client: Selected g03m01.4830.org:10001 as the best broker.
Wed Jul 20 02:42:01 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_GET_COOKIE, asking for some ...
Wed Jul 20 02:42:01 2022 daemon.info td-client: [g03m01.4830.org:10001] Broker is in STATE_GET_TUNNEL, sending request.
Wed Jul 20 02:42:01 2022 daemon.info td-client: [g03m01.4830.org:10001] Tunnel successfully established.
Wed Jul 20 02:42:13 2022 daemon.info td-client: [g03m01.4830.org:10001] Setting MTU to 1364

Soweit ich das sehe, schickten g01m01.4830.­org und g02m01.4830.­org augenscheinlich keine Usage-Daten zurück und fielen daher aus der Gateway-/Brokerwahl. Jedenfalls werden im positiven wie negativen Fall von connect() die aufgelösten IP-Adressen geloggt — darüber sollte sicht auch dieser Nebel lichten.

1 „Gefällt mir“
9

Gerade hier nochmal aufgetreten, bei mir war tatsächlich einfach kein WAN DNS-Server gesetzt, die Datei war einfach leer. Manuelles befüllen bzw. korrektes statisches Setzen hat scheinbar Abhilfe geschaffen:

root@HAW-Gluon-Uplink:~# cat /var/gluon/wan-dnsmasq/resolv.conf 
nameserver 192.168.254.254 #war vorher leer
root@HAW-Gluon-Uplink:~# uci show|grep dnsmas
gluon-wan-dnsmasq.@static[0]=static
gluon-wan-dnsmasq.@static[0].server='192.168.254.254'