Ich habe jetzt immerhin herausgefunden, warum er nur einen Tunnel anlegen kann. Aber das wirft dann die Frage auf, warum das jemals geklappt hat…
Wie sich rausstellt, kann man mit tcpdump netfilter-Pakete abfangen. Damit konnte ich dann sehen, dass tatsächlich eine der Netfilter-Queries vom Tunneldigger schief geht. Eigentlich hat Tunneldigger Code, um solche Fehler zu erkennen und zu melden, aber der hatte einen Bug. Folgender Commit behebt den Fehler in der Fehlererkennung:
Damit sehe ich jetzt immerhin, dass das Erstellen einer L2TP-Session im schon aufgebauten L2TP-Tunnel schief geht. Fehler: EEXIST. Offenbar ist der Kernel der Meinung, die session ID würde schon verwendet. Nun, die session ID ist immer 1 (das ist im Client sogar hard-coded), aber das sind ja sessions in verschiedenen Tunneln. Ich habe lange gesucht und durch den Kernel-Quelltext geschaut, um herauszufinden, ob session IDs jetzt global oder pro Tunnel eindeutig sein müssen – und schließlich folgenden Kommentar im Kernel gefunden:
/* In L2TPv3, session_ids are unique over all tunnels and we
* sometimes need to look them up before we know the
* tunnel.
*/
Der Kommentar existiert in v4.12 nicht mehr, weil die ganze Funktion entfernt wurde – aber das muss ja nicht heißen, dass er nicht mehr gültig ist. Es gibt immer noch Code, der eine globale Liste aller Sessions verwaltet.
Wenn das richtig ist, dass die session IDs global eindeutig sein müssen, dann wären auch Änderungen am Client nötig – schließlich muss jedes Ende des L2TP-Tunnels die session ID der anderen Seite kennen.
Was mich gerade am meisten wundert, ist, dass das ganze früher überhaupt geklappt hat. Gab es einen Bug im Kernel, sodass doppelte session IDs akzeptiert wurden? Oder was ist hier los? Und wenn das bei euch alles klappt – welche Kernel-Version verwendet ihr? Ich habe 4.9 und 4.12 probiert und mit beiden das gleiche Problem.
EDIT: Aha! Im alten Kernel gab es zwar die Liste auch schon, aber er hat nicht geprüft, ob da Einträge doppelt drin sind. Und mit Version v4.9.36 landete dann folgender Commit:
https://github.com/linux-stable/linux-stable/commit/d9face6fc62a73059f0fc3a3de4dfe8f53536aa7
und seit dem werden die IDs korrekt geprüft. Und vermutlich habt ihr alle euer Debian 9 installiert bevor v4.9.36 in Debian ankam? Das würde dann alles erklären – aber das Problem nicht lösen.