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
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.
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
<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>
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
(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«.)
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