Wireguard-Anomalien

Moin,

wir verwenden zum Verbinden einzelner Serverinseln derzeit Wireguard und haben damit komische Probleme: lt. „wg“ steht die Verbindung, aber auf einer Seite (Ubuntu 20.04 LTS, Kernel 5.4.0) funktioniert die Verbindung nicht, „ping“ kommt mit falscher Fehlermeldung zurück. Die Route existiert, eigentlich (IP-Adressen anonymisiert):

root@DC01HV01 ~ # ip addr show dev W1DC201
15: W1DC201: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 7.8.8.61/30 brd 7.8.8.63 scope global W1DC201
       valid_lft forever preferred_lft forever
root@DC01HV01 ~ # wg
interface: W1DC201
  public key: V…=
  private key: (hidden)
  listening port: 46157
  fwmark: 0x1

peer: T…=
  endpoint: [2001:db8:100:b00::4]:46157
  allowed ips: 7.8.8.60/30
  latest handshake: 56 seconds ago
  transfer: 64.51 MiB received, 1.43 MiB sent
root@DC01HV01 ~ # ping 7.8.8.62
ping: connect: No route to host
root@DC01HV01 ~ # ip route get 7.8.8.62
RTNETLINK answers: No route to host
root@DC01HV01 ~ # ip route show | grep ^7.8
7.8.8.60/30 dev W1DC201 proto kernel scope link src 7.8.8.61 
7.8.9.12/30 dev …
7.8.9.44/30 dev …
root@DC01HV01 ~ # ip rule show | grep ^7.8
root@DC01HV01 ~ # 

Gegenstelle:

root@DC02HV01:~# ip addr show W1DC101
121: W1DC101: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 7.8.8.62/30 brd 7.8.8.63 scope global W1DC101
       valid_lft forever preferred_lft forever
root@DC02HV01:~# wg
[…]
interface: W1DC101
  public key: T…=
  private key: (hidden)
  listening port: 46157
  fwmark: 0x1

peer: V…=
  endpoint: [2001:db8:c000:40::189]:46157
  allowed ips: 7.8.8.60/30
  latest handshake: 6 seconds ago
  transfer: 434.63 MiB received, 1.38 GiB sent
root@DC02HV01:~# ping 7.8.8.61
PING 7.8.8.61 (7.8.8.61) 56(84) bytes of data.
^C
--- 7.8.8.61 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7091ms

Kennt jemand solche Probleme?

Ja, hatte ich auch mal.
Aber was habe ich gemacht, dass es wegging… jetzt rächt sich wieder, dass es Configs gibt, die nicht im Git liegen.
Ich meine es war irgendwas mit einem „unsymetrisch falsch eingetragenen Peering“, was dazu führt, dass ein Knoten A sich mit seiner Gegenstelle B zu verbinden versuchte, unter einer inkorrekten IP/DNS (->Gegenstelle C). Und währendessen scheiterten die Verbindungsversuche in der Gegenrichtung (B->A), weil A beschäftigt war, sich noch mit C „zu streiten“.
Das Flapping dabei sorgte dann für Zustände in denen dann wg show zwar irgendwie connected sagte, aber Routen nicht gesetzt waren oder aber ping mit „impossible/unreachable“(?) beantwortet wurden.

Wegen solcher Probleme sind auf dem Port Quell- und Zieladressen als einzige zugelassen:

Chain INPUT (policy ACCEPT 6918M packets, 4498G bytes)
 pkts bytes target     prot opt in     out     source               destination         
 668K  488M ACCEPT     udp      *      *       2001:db8:c000:40::189  2001:db8:100:b00::4  udp dpt:46157
    0     0 DROP       udp      *      *       ::/0                 2001:db8:100:b00::4  udp dpt:46157

Und wg sagt ja (auf beiden Seiten) „latest handshake: 1 minute, 57 seconds ago“. Auf WireGuard-Ebene scheint es zu tun, nur das Interface WireGuard<>Kernel scheint in 5.4.0 karpott.

ich meine, dass das „latest handshake“ (mit sinvoll niedrigen Zeitangaben) im Fehlerzustand auch vorhanden war. Nur gab dann ping irgendeine (mir bislang nicht geläufige) Fehlermeldung der Art „not allowed“, oder „can’t send“… ist schon etwas her, erinnere mich nicht. War nur etwas das roch(!) wie „$user hat nicht genug Rechte“ (was es natürlich nicht war, aber nur zur Einordnung.)

Aber solche Rückmeldungen bekommst Du ja nicht.
Lässt sich das irgendwie tcpdumpen, ob die Pakete zumindest undirektional laufen?

Wenn WireGuard den Peer (noch) nicht kennt, wirft ping eine esoterische Meldung in die Richtung, IIRC „Key unbekannt“ oder so.

Der traceroute läuft korrekt, das Routing von Quelle zu Ziel ist per ip rule auf eine eigene Tabelle gezwungen, die auch per fwmark von wg adressiert wird. Ich sehe gerade nicht, wo ich noch gucken sollte; die Meldung „no route to host“, die bei „ip get“ auch kommt, obwohl „ip route show“ ja die Route aufistet, ist auch nicht hilfreich. „if down“ gefolgt von „if up“ hat nichts geändert :frowning:

<ObRant> Genau wegen so einer Grütze nutzte ich i. d. R. nur gut abgehangene Releases und nur heterogene solche untereinander. Die Frage, ob Ubuntu 20.04 LTS einsetzbar ist, ist also zu verneinen; ich hasse es, wenn mein Bauchgefühl recht hat — was es leider fast immer hat. </ObRant>

1 „Gefällt mir“

Nachtrag: Ich pinge von „W1DC101“, das kommt auf „W1DC201“ an, geht aber nicht raus:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on W1bgpgut01, link-type RAW (Raw IP), capture size 262144 bytes
03:47:27.414384 IP 7.8.8.62.32061 > 7.8.8.61.32061: UDP, length 54
03:47:27.758284 IP 7.8.8.62 > 7.8.8.61: ICMP echo request, id 59059, seq 31, length 64
03:47:28.448622 IP 7.8.8.62.32061 > 7.8.8.61.32061: UDP, length 54
03:47:28.764852 IP 7.8.8.62 > 7.8.8.61: ICMP echo request, id 59059, seq 32, length 64
03:47:29.469490 IP 7.8.8.62.32061 > 7.8.8.61.32061: UDP, length 54
03:47:29.788825 IP 7.8.8.62 > 7.8.8.61: ICMP echo request, id 59059, seq 33, length 64
03:47:30.382603 IP 7.8.8.62.32061 > 7.8.8.61.32061: UDP, length 102
03:47:30.493195 IP 7.8.8.62.32061 > 7.8.8.61.32061: UDP, length 54
03:47:30.788575 IP 7.8.8.62 > 7.8.8.61: ICMP echo request, id 59059, seq 34, length 64
^C

(Die UDP-Pakete sind vom L2TP-Tunnel, über den der eigentliche Traffic laufen sollte.)

Entsprechend:

root@DC02HV01:~# ping 7.8.8.61
PING 7.8.8.61 (7.8.8.61) 56(84) bytes of data.
^C
--- 7.8.8.61 ping statistics ---
192 packets transmitted, 0 received, 100% packet loss, time 192431ms

Im tcpdump kommt auch nix an, man sieht die Pakete nur rausgehen.

BEBKAC, sort of.

root@DC01HV01 ~ # ip rule show
0:      from all lookup local
30000:  from 192.0.2.189 lookup 1
32000:  from all lookup 42
32766:  from all lookup main

Tabelle Main hat die Route, Tabelle 42 … nicht. Insofern findet „ip route get“ die Route richtigerweise nicht, die „ip route show [table main]“ durchaus anzeigt. protocol direct { interface "W*"; } und schon tut’s (wieder), da Bird Tabelle 42 befüllt. (Nur DC01HV01 nutzt dieses Setup als auch Ubuntu 20.04, da als jüngstes aufgesetzt und damit Versuchkanninchen für 20.04 als auch das neue, Ansible-basierte Setup — die anderen Systeme nutzten noch einen anderen Routingansatz, 16.04 und Puppet. Wobei nichts davon miteinander zu tun hat.)

Danke für die Reflektion; manches wird erst klar, wenn man es anderen zu erklären versucht :dizzy_face:

(Ubuntu 20.04 hat mich auf dem Server schon massiv Nerven gekostet, u. a. weil etliche 3rd-Party-Repos, gerade für Raid oder BMC, zum Installationszeitpunkt im Juni von 20.04 noch nichts gehört hatten. Der Wechsel von Python2 auf Python3 war auch nicht hilfreich … Ist »halt wieder so eine Version«; die letzten blutigen Finger hatte ich bei Debian Jessie, initial auch keine Wahl für »mal eben schnell«.)

Klingt nach erfolgreichem Rubberduck-Debugging!

1 „Gefällt mir“

Indeed; den Begriff kannte ich noch nicht. Aber da selbst die Hündin um diese Zeit schläft, und ich beim Versuch, es mir selbst zu erklären, erfahrungsgemäß zuviele »Selbständigkeiten« weglasse (die manchmal gar nicht selbstverständlich, sondern nur falsche Ausgangsparameter, sind): Danke, lieber @adorfer, daß Du wieder mal meine Gummiente warst :wink: