Aktionstabelle: Verbindungsaufbau Aktion nach xSec ausführen

[Bernie137]

Hallo zusammen,

ich möchte einen Befehl beispielsweise nach 300 Sekunden absetzen, nachdem der Verbindungsaufbau erfolgreich war und die Leitung seitdem auch nicht wieder getrennt wurde. Wie stellt ich das am besten an? Eine Art "wait" gibt es scheinbar nicht.

Die Sperrzeit hilft mir nach meiner Auffassung nicht weiter, da der Befehl trotzdem sofort ausgeführt wird, aber dann eine gewisse Zeit nicht wiederholt wird. Ich überlege jetzt schon wegen Verkettung, habe aber noch keine zündende Idee.

vg Bernie

[hyperjojo]

hi,

Eine Art "wait" gibt es scheinbar nicht.

Auf der Konsole gibt es "sleep". Ob das auch in der Aktionstabelle nutzbar ist, habe ich noch nicht getestet...

Gruß hyperjojo

[Bernie137]

Hallo,

Auf der Konsole gibt es "sleep". Ob das auch in der Aktionstabelle nutzbar ist, habe ich noch nicht getestet...

Vermutlich ist das nutzbar, aber das bringt den großen Nachteil, dass auch alle anderen Scripte wohl für diese Zeit ausgesetzt werden. Und ich hätte lieber in der Zwischenzeit auch eine zyklische Prüfung der Verbindung. Aber erst mal danke für die Idee.



Kann es sein, dass man Aktionen, welche mit "exec:..." beginnen, keine Ergebnis-Auswertung machen kann? Mir ist das nicht gelungen, z.B. mit ping...

Code: Alles auswählen

exec:ping -c 1 192.168.10.1;     contains=192.168.10.1?skipiftrue1

...wird beispielsweise nie ausgewertet (IP im Remote-Netz des VPN-Tunnel).

vg Bernie

[backslash]

hi Bernie137

Kann es sein, dass man Aktionen, welche mit "exec:..." beginnen, keine Ergebnis-Auswertung machen kann?

doch, das geht...

Mir ist das nicht gelungen, z.B. mit ping...

Code: Alles auswählen

exec:ping -c 1 192.168.10.1;     contains=192.168.10.1?skipiftrue1

...wird beispielsweise nie ausgewertet (IP im Remote-Netz des VPN-Tunnel).

hier hast du das Problem, daß das ping asysnchron zur CLI-Session läuft, wodurch die Session defakto schon wieder beendet wird, bevor das ping starten konnte. hier brauchst du definitiv ein sleep nach dem ping, also

Code: Alles auswählen

exec:ping -c 1 192.168.10.1; sleep 10s    contains=192.168.10.1?skipiftrue1

Gruß
Backslash

[Bernie137]

Hallo,

danke backslash für Deinen Tipp. Ich habe es nun aber anders gelöst.

Es ist ja im Prinzip alles dokumentiert bei Lancom. Ich bin jedoch ein Mensch, der anhand von Beispielen oftmals wesentlich besser lernen kann. Da gibt es meiner Meinung nach nicht so viele Beispiele bei Lancom. Daher möchte ich meine wenigen Zeilen hier posten - nicht weil jemand den gleichen Anwendungsfall hätte, da ist meiner wohl viel zu speziell - aber vielleicht hilft es dem einen oder anderen im Allgemeinen weiter.

Sinn und Zweck des Scriptes ist, dass wenn ein bestimmter von drei VPN-Tunneln über einen schnelleren Provider aufgebaut wurde und diese Verbindung min. 5 Minuten Bestand hat, dass dann sämtlicher RDP Traffic über diesen Tunnel läuft. Es gab Tage, da hat die Verbindung dieses Providers in der Art gehaspelt, dass alls 2 bis 3 Minuten der VPN-Tunnel getrennt wurde - und das über Stunden.

Code: Alles auswählen

ls /Setup/WAN/Action-Table/

Index  Host-Name     Peer       Lock-Time  Action                                                                      Check-For                      Owner  Routing-Tag
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1      SATKABEL_RDP  ZENTRALE3  0          exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                   contains=0:05?skipiftrue=1     root   0
2      SATKABEL_RDP  ZENTRALE3  0          repeat:30                                                                   contains=NEVER?skipiffalse=1   root   0
3      SATKABEL_RDP  ZENTRALE3  0          exec:set /setup/ip-router/firewall/rules/TAGGING_RDP {Firewall-Rule}  yes                                  root   0
4      BACKUP_RDP    ZENTRALE3  120        exec:set /setup/ip-router/firewall/rules/TAGGING_RDP {Firewall-Rule}  no                                   root   0

Bei der zu prüfenden Verbindung handelt es sich um eine VPN-Verbindung ZENTRALE3.
Index 1 liest aus der Tabelle /status/vpn/connections/Zentrale3 die conn.-time und prüft, ob die Verbindungszeit einen Wert 0:05 Minuten hat, wenn wahr dann wird Index 2 übersprungen, wenn falsch wird Index 2 ausgeführt
Index 2 wiederholt die Schleife alle 30 Sekunden und prüft auf die niemals erfüllbare Bedingung "NEVER" und überspringt damit bei jedem Durchlauf Index 3
Index 3 wird nur ausgeführt, wenn die Bedingung bei Index 1 wahr wird und damit Index 2 übersprungen wird (Abbruch der Schleife)
Index 4 gehört nicht zur Schleife und regelt den RDP Traffic wieder über die anderen zuverlässiger bestehenden aber langsameren Verbindungen des VPN Load-Balancers. Die Sperrzeit soll ein dauerndes Schreiben auf den Flash verhindern, wenn die VPN-Verbindung "ZENTRALE3" haspelt.

Den Ablauf des Scriptes kann man sich anschauen über ls /status/wan/actions/action-table

Code: Alles auswählen

> ls /Status/WAN/Actions/Action-Table/

Time                  Action                                                                              Result
---------------------------------------------------------------------------------------------------------------------------------------------------
03/23/2016 15:47:22   exec:set /setup/ip-router/firewall/rules/TAGGING_RDP {Firewall-Rule}  yes           set ok
03/23/2016 15:47:22   exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                           Conn.-time               INFO:    0:05:00
03/23/2016 15:46:52   repeat:30                                                                           timer started
03/23/2016 15:46:52   exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                           Conn.-time               INFO:    0:04:30
03/23/2016 15:46:22   repeat:30                                                                           timer started
03/23/2016 15:46:22   exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                           Conn.-time               INFO:    0:04:00
03/23/2016 15:45:52   repeat:30                                                                           timer started
03/23/2016 15:45:52   exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                           Conn.-time               INFO:    0:03:30
03/23/2016 15:45:22   repeat:30                                                                           timer started
03/23/2016 15:45:22   exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                           Conn.-time               INFO:    0:03:00
03/23/2016 15:44:52   repeat:30                                                                           timer started
03/23/2016 15:44:52   exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                           Conn.-time               INFO:    0:02:30
03/23/2016 15:44:22   repeat:30                                                                           timer started
03/23/2016 15:44:22   exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                           Conn.-time               INFO:    0:02:00
03/23/2016 15:43:52   repeat:30                                                                           timer started
03/23/2016 15:43:52   exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                           Conn.-time               INFO:    0:01:30
03/23/2016 15:43:22   repeat:30                                                                           timer started
03/23/2016 15:43:22   exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                           Conn.-time               INFO:    0:01:00
03/23/2016 15:42:52   repeat:30                                                                           timer started
03/23/2016 15:42:52   exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                           Conn.-time               INFO:    0:00:30
03/23/2016 15:42:23   repeat:30                                                                           timer started
03/23/2016 15:42:23   exec:cd /status/vpn/connections/ZENTRALE3 ; ls conn.-time                           Conn.-time               INFO:    0:00:01
03/23/2016 15:42:22   exec:set /setup/ip-router/firewall/rules/TAGGING_RDP {Firewall-Rule}  no

Damit wird nicht nach exakt 300 Sekunden der Befehl ausgeführt, sondern nach min. 5 Minuten, da kann auch 5:27 Minuten bei rauskommen.

Leider kann man das Script nicht 1 zu 1 anwenden für WAN Verbindungen. Denn die Tabelle ls /status/remote-connections hat als Index die Spalte conn.-start (Datum-Zeit Format), welche man schlecht automatisiert ansprechen kann. Eine unsaubere Lösung wäre mit der Tabelle ls /status/connection zu arbeiten, aber da ist es wohl nicht der gesicherte Verbindungsaufbau.

Habt ihr Anregungen, Kritik, Verbesserungsvorschläge?

Gruß Bernie

[Dr.Einstein]

Hallo Bernie,

finde es super, dass du uns das Beispiel gepostet hast. Verwende so eine Verkettung von Aktionen viel selten, auch aus Unwissenheit. Klasse, danke.

Gruß Dr.Einstein

[Bernie137]

Hallo Dr. Einstein,

Verwende so eine Verkettung von Aktionen viel selten, auch aus Unwissenheit.

Ich auch. Daher habe ich auch länger daran gebastelt. Die Verkettung/Schleife war gar nicht so das Problem, eher was man sinnvollerweise auswertet. In meinem Fall die Verbindungszeit.

vg Bernie