OpenConnect kann VPN-only-Ziele nicht erreichen

Question 1

Basierend auf KRyans Antwort habe ich mein Openconnect-Skript (vpnc-script.js im Openconnect-GUI-Ordner!) wie folgt geändert und es hat mir in einer ähnlichen Situation geholfen:

for (var i = 0 ; i < parseInt(env("CISCO_SPLIT_INC")); i++) {
        var network = env("CISCO_SPLIT_INC_" + i + "_ADDR");
        var netmask = env("CISCO_SPLIT_INC_" + i + "_MASK");
        var netmasklen = env("CISCO_SPLIT_INC_" + i + "_MASKLEN");
        exec("route add " + network + " mask " + netmask);
    }

=>

for (var i = 0 ; i < parseInt(env("CISCO_SPLIT_INC")); i++) {
        var network = env("CISCO_SPLIT_INC_" + i + "_ADDR");
        var netmask = env("CISCO_SPLIT_INC_" + i + "_MASK");
        var netmasklen = env("CISCO_SPLIT_INC_" + i + "_MASKLEN");
        exec("route add " + network + " mask " + netmask + " " + internal_gw+" metric 2 if "+env("TUNIDX"));
    }

(Zeile 175)

Der Fehler liegt meiner Meinung nach hier:

// Calculate the first usable address in subnet
var internal_gw_array = new Array(
    address_array[0] & netmask_array[0],
    address_array[1] & netmask_array[1],
    address_array[2] & netmask_array[2],
    (address_array[3] & netmask_array[3]) + 1
);
var internal_gw = internal_gw_array.join(".");

Mit einer Netzmaske von 255.255.255.255 für meine interne IP, die von übergeben wird var netmask_array = env("INTERNAL_IP4_NETMASK").split(".");, scheint dieser Gateway-Trick (letztendlich geht eine Route zu einer Schnittstelle, die Gateway-IP ist hier sinnlos) zu scheitern

Answer

Basierend auf KRyans Antwort habe ich mein Openconnect-Skript (vpnc-script.js im Openconnect-GUI-Ordner!) wie folgt geändert und es hat mir in einer ähnlichen Situation geholfen:

for (var i = 0 ; i < parseInt(env("CISCO_SPLIT_INC")); i++) {
        var network = env("CISCO_SPLIT_INC_" + i + "_ADDR");
        var netmask = env("CISCO_SPLIT_INC_" + i + "_MASK");
        var netmasklen = env("CISCO_SPLIT_INC_" + i + "_MASKLEN");
        exec("route add " + network + " mask " + netmask);
    }

=>

for (var i = 0 ; i < parseInt(env("CISCO_SPLIT_INC")); i++) {
        var network = env("CISCO_SPLIT_INC_" + i + "_ADDR");
        var netmask = env("CISCO_SPLIT_INC_" + i + "_MASK");
        var netmasklen = env("CISCO_SPLIT_INC_" + i + "_MASKLEN");
        exec("route add " + network + " mask " + netmask + " " + internal_gw+" metric 2 if "+env("TUNIDX"));
    }

(Zeile 175)

Der Fehler liegt meiner Meinung nach hier:

// Calculate the first usable address in subnet
var internal_gw_array = new Array(
    address_array[0] & netmask_array[0],
    address_array[1] & netmask_array[1],
    address_array[2] & netmask_array[2],
    (address_array[3] & netmask_array[3]) + 1
);
var internal_gw = internal_gw_array.join(".");

Mit einer Netzmaske von 255.255.255.255 für meine interne IP, die von übergeben wird var netmask_array = env("INTERNAL_IP4_NETMASK").split(".");, scheint dieser Gateway-Trick (letztendlich geht eine Route zu einer Schnittstelle, die Gateway-IP ist hier sinnlos) zu scheitern

Question 2

Ich hatte recht, dass die Routen das Problem waren. Es hat viel Ausprobieren gekostet, bis es richtig war, aber schließlich hat das manuelle Aktualisieren der Routen nach der Verbindung funktioniert.

Seltsamerweise route CHANGEhat das nicht funktioniert. Ich musste verwenden route ADD, obwohl diese Routen meines Wissens nach bereits existierten, nachdem ich die Verbindung hergestellt hatte. Ich habe dasselbe Ziel, dieselbe Maske und dasselbe Gateway verwendet und dann METRIC 2 IF 17(da die Schnittstelle „TAP-Windows-Adapter V9“ 17 verwendete – ich vermute, das ändert sich bei jedem Neustart?) scheint beim Trennen und Wiederherstellen der Verbindung derzeit durchgängig 17 zu verwenden, aber wie Sie der Frage entnehmen können, wurde damals 63 verwendet. Nachdem ich dies getan hatte, waren route PRINTfür dieses Ziel zwei Einträge in aufgeführt (der von OpenConnect hinzugefügte und der von mir hinzugefügte) und ich konnte eine Verbindung herstellen.

Was ich allerdings absolut bizarr finde, ist, dass meine neu hinzugefügte Route eine Metrik von 37 hat – nicht die 2, die ich in den route ADDBefehl eingegeben habe, und größer als die 36, die der vorhandene Eintrag hatte. Aber egal, es funktioniert.

Glücklicherweise verwaltet unser Projekt eine hostsDatei (die Entwickler in ihre eigene Datei kopieren können, hostswenn sie mit der Arbeit beginnen, und die unsere Build-Tools überprüfen), sodass ich ein Batch-Skript schreiben konnte, um die Routen anzupassen. Für alle anderen, die dies auch tun möchten, sieht mein Batch-Skript so aus:

FOR /F "tokens=1" %%i IN (\path\to\our\development\hosts) DO (
    route ADD %%i MASK 255.255.255.255 a.b.c.d METRIC 2 IF 17
)

Das hostsDateiformat ist das gleiche wie das der Systemdatei: a.b.c.d URL. Dieses Skript unterstützt keine Kommentare (obwohl ich mir vorstellen kann, dass das route ADDeinfach fehlschlagen wird) und ich weiß nicht, ob leere Zeilen ein Problem darstellen oder nicht (aber wiederum ist es wahrscheinlich nur ein fehlgeschlagener route ADD).

Ich werde es wahrscheinlich für diese 17 anpassen müssen, da ich vermute, dass das nicht konstant sein wird; wenn das passiert, werde ich untersuchen, wie man es bestimmt, und stattdessen eine Variable dafür verwenden. (Und ich werde diese Antwort auch aktualisieren.)

Answer

Ich hatte recht, dass die Routen das Problem waren. Es hat viel Ausprobieren gekostet, bis es richtig war, aber schließlich hat das manuelle Aktualisieren der Routen nach der Verbindung funktioniert.

Seltsamerweise route CHANGEhat das nicht funktioniert. Ich musste verwenden route ADD, obwohl diese Routen meines Wissens nach bereits existierten, nachdem ich die Verbindung hergestellt hatte. Ich habe dasselbe Ziel, dieselbe Maske und dasselbe Gateway verwendet und dann METRIC 2 IF 17(da die Schnittstelle „TAP-Windows-Adapter V9“ 17 verwendete – ich vermute, das ändert sich bei jedem Neustart?) scheint beim Trennen und Wiederherstellen der Verbindung derzeit durchgängig 17 zu verwenden, aber wie Sie der Frage entnehmen können, wurde damals 63 verwendet. Nachdem ich dies getan hatte, waren route PRINTfür dieses Ziel zwei Einträge in aufgeführt (der von OpenConnect hinzugefügte und der von mir hinzugefügte) und ich konnte eine Verbindung herstellen.

Was ich allerdings absolut bizarr finde, ist, dass meine neu hinzugefügte Route eine Metrik von 37 hat – nicht die 2, die ich in den route ADDBefehl eingegeben habe, und größer als die 36, die der vorhandene Eintrag hatte. Aber egal, es funktioniert.

Glücklicherweise verwaltet unser Projekt eine hostsDatei (die Entwickler in ihre eigene Datei kopieren können, hostswenn sie mit der Arbeit beginnen, und die unsere Build-Tools überprüfen), sodass ich ein Batch-Skript schreiben konnte, um die Routen anzupassen. Für alle anderen, die dies auch tun möchten, sieht mein Batch-Skript so aus:

FOR /F "tokens=1" %%i IN (\path\to\our\development\hosts) DO (
    route ADD %%i MASK 255.255.255.255 a.b.c.d METRIC 2 IF 17
)

Das hostsDateiformat ist das gleiche wie das der Systemdatei: a.b.c.d URL. Dieses Skript unterstützt keine Kommentare (obwohl ich mir vorstellen kann, dass das route ADDeinfach fehlschlagen wird) und ich weiß nicht, ob leere Zeilen ein Problem darstellen oder nicht (aber wiederum ist es wahrscheinlich nur ein fehlgeschlagener route ADD).

Ich werde es wahrscheinlich für diese 17 anpassen müssen, da ich vermute, dass das nicht konstant sein wird; wenn das passiert, werde ich untersuchen, wie man es bestimmt, und stattdessen eine Variable dafür verwenden. (Und ich werde diese Antwort auch aktualisieren.)

Question 3

Nicht, dass Sie nicht bereits etwas herausgefunden hätten, das funktioniert, aber Sie scheinen die Verwendung der Routenmetriken falsch zu verstehen.Sie sind eigentlich nur in ganz bestimmten Situationen ein Entscheidungskriterium.. Zitat aus der verlinkten Antwort:

Die Routenauswahl unter Windows umfasst:

Finden der genauesten Routen zum Ziel

Auswahl der spezifischsten Route mit der niedrigsten Metrik.

Und wenn Sie Ihr Skript weniger anfällig machen möchten, können Sieprogrammgesteuerte Ermittlung der Schnittstellennummer.

Answer

Nicht, dass Sie nicht bereits etwas herausgefunden hätten, das funktioniert, aber Sie scheinen die Verwendung der Routenmetriken falsch zu verstehen.Sie sind eigentlich nur in ganz bestimmten Situationen ein Entscheidungskriterium.. Zitat aus der verlinkten Antwort:

Die Routenauswahl unter Windows umfasst:

Finden der genauesten Routen zum Ziel

Auswahl der spezifischsten Route mit der niedrigsten Metrik.

Und wenn Sie Ihr Skript weniger anfällig machen möchten, können Sieprogrammgesteuerte Ermittlung der Schnittstellennummer.

OpenConnect kann VPN-only-Ziele nicht erreichen

Antwort1

Antwort2

Antwort3

verwandte Informationen