DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Forum zum Thema Firewall

Moderator: Lancom-Systems Moderatoren

Antworten
root-ing
Beiträge: 5
Registriert: 21 Mai 2020, 11:27

DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von root-ing »

Hallo zusammen.

Ich möchte hier mal nicht direkt eine Frage stellen, sondern meine Lösung für ein Problem vorstellen. Ich würde mich über Rückmeldungen bzw. Optimierungsvorschläge sehr freuen.

Problembeschreibung:

Eine Port-Weiterleitung ist für einen internen Server eingerichtet (z.B. Port 443). In der Firewall ist eine - deny-all-Regel – angelegt. Über eine zweite Regel werden einzelne Stationen über ihre IP freigegeben.
Soweit ist alles gut.
Nun hatte ich das Problem das es zwei Kunden gibt die keine feste öffentliche IP besitzen und das auch nicht ändern möchten. Eine Suche hier im Forum zeigte schon das Lancom keine DNS Einträge (z.B. srvKunde1.no-ip.org) zur Definition bei den Stations-Objekten zu lässt.

Der Support von Lancom hat dies ebenfalls bestätigt und auch betont das es hier keine Lösung in naher Zukunft geben wird!

Für mich stellt das ein riesen Problem dar, weil ich keine Lust habe alle 24h nach einer Providerzwangstrennung die neuen IP Adressen nachzutragen.
Da viele meiner anderen Firewalls die ich betreue das können, war das keine haltbare Situation

Hier mein Workaround!


Voraussetzung:
1. Die Firewall ist konfiguriert und die Regel funktioniert mit den statischen Stationsobjekten; Des Weiteren sind die dynamischen Clients mit ihrer aktuellen IP (oder einer Phantasie IP: 123.123.123.123) als Stations-Objekt eingerichtet. Für dieses Bsp.: Die Station „srvKunde1“

2. Ein Linux Client ist im internen Netz hinter dem Lancom und hat Internetzugang. Da ich eine Vielzahl von Server betreibe war das für mich kein Problem. Denkbar sind hier VMs/Raspberry Pi/Webserver. Diese Aufgabe schafft jedes Linuxsystem nebenbei, es ist also nicht nötig extra einen Server dafür zu bauen.

WICHTIG! Bitte keinen externen Server der im Internet steht (z.B. Webserver) dafür verwenden. Ich halte das dann für extrem unsicher. Für mich funktioniert das nur sicher wenn der Server im internen Netz aufgebaut worden ist.

3. Auf dem Linux System ist SED (https://de.wikipedia.org/wiki/Sed_(Unix)) installiert und ein kleiner tFtp Server (in diesem Beispiel mit der IP: 192.168.0.99) ist konfiguriert & einsatzbereit.

Umsetzung:

Auf dem Linuxserver:

Der Linux Client soll per CronJob regelmäßig den Kunden Server srvKunde1.no-ip.org auslesen und die aktuelle IP Adresse erfassen.
Im Anschluss soll die ausgelesene IP in eine Lancom-Skriptdatei „srvKunde1dynip.lcs“ geschrieben bzw. aktualisiert werden.

Per Lancom Cronjob soll dann das Skript geladen und die IP geändert werden.

Code für den Linuxserver:
Der tFtp Server verwendet das Verzeichnis /var/tftp, somit müssen alle Dateien hier abgelegt werden.

1. Anlegen einer Batchdatei: „nano srvKunde1.sh“

Code: Alles auswählen

#!/bin/bash

# Wechselt in das Arbeitsverzeichnis
cd /var/tftp

# Fragt die IP der Domain „srvKunde1.no-ip.org“ ab und kürzt die Ausgabe nur auf die IP zu. Schreibt die IP in die Datei „srvKunde1.ip“. 
# Die Datei wird beim ersten Ausführen automatisch angelegt!

host srvKunde1.no-ip.org|grep address|sed 's/.*address //g' > srvKunde1.ip 

# Zieht sich die IP aus der Datei „srvKunde1.ip“. Sucht in der Skriptdatei „srvKunde1dynip.lcs“ nach dem Muster 123.123.123.123 und ersetzt 
# dieses mit dem Inhalt (z.B. 345.345.345.345) aus „srvKunde1.ip“.

sed -i "s/[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}/$(<srvKunde1.ip)/g" srvKunde1dynip.lcs


2. Datei abspeichern und ausführbar machen: „chmod +x srvKunde1.sh“

3. Anlegen der Skriptdatei: „nano srvKunde1dynip.lcs“

Code: Alles auswählen

lang English
flash No
cd /
cd /Setup/IP-Router/Firewall/Objects
#    Name                              Description                             $
#    ==================================----------------------------------------$
add  " srvKunde1"                            {Description}  "%A123.123.123.123"
cd /
flash Yes
# done
exit
4. Datei abspeichern

5. Ausführen der Batchdatei “./srvKunde1.sh“

6. Den Inhalt der Skriptdatei prüfen: „less srvKunde1dynip.lcs“. Nun müsste die aktuelle IP der Station in der Datei
eingetragen worden sein. BSP.: „%A456.456.456.456“

7. CronJob erstellen: „crontab –e“

Code: Alles auswählen

# Führt das Skript  “srvKunde1.sh“ um 3:30 Uhr aus
30 3 * * * /var/tftp/ srvKunde1.sh #DynIP Update for srvKunde1
8. Cronjob speichern.

Nun ist alles auf der Linuxseite konfiguriert!

Auf dem Lancom

1. Lanconfig in die Cronjob-Tabelle wechseln. Dort einen neuen Cronjob erstellen:

Unter dem Punkt „Befehle“ folgendes eintragen: LoadScript -s 192.168.0.99 -f srvKunde1dynip.lcs
crontable.JPG
2. Anmerkung: Will man den Cronjob zum testen jede Minute ausführen (auf dem Lancom), muss man einfach alle Angaben freilassen. Trägt man 1 oder 01 bei „Minuten“ ein, läuft das Skript nur in der „ersten“ Minute jeder Stunde. Das hat mich etwas Zeit gekostet das heraus zu finden.

Fertig! Problem gelöst. :D

Ich würde mich freuen über Rückmeldungen. Da es SED auf dem Lancom nicht gibt und die Shell ja eigenen Regeln folgt konnte ich das nur außerhalb lösen. Evtl. hat ja auch jemand mehr Erfahrungen damit?

Ich lasse den Cronjob nur einmal pro Tag laufen, weil ich nur einmal am Tag die richtig IP brauche bevor ein Job auf dem Server läuft. Es wäre aber auch denkbar, dass man die andere Seite (Lancom beim Kunden) eine Email versenden lässt wenn sich die IP ändert und damit den Cronjob triggert. Das war mir aber zu aufwendig.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von GrandDixence »

Sinnvoller und sicherer wäre es, wenn sich die Kunden per VPN-Tunnel zum internen Server verbinden. Ausser den Kunden muss niemand Zugriff auf diesen Server erhalten. Da IKEv2/IPSEC defacto "Industriestandard" ist, sollte das kein Problem sein...

Für VPN-Anleitungen siehe:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von Jirka »

root-ing hat geschrieben: 27 Mai 2020, 15:46 die andere Seite (Lancom beim Kunden)
Ist es dann nicht einfacher, wenn man da einfach eine VPN aufbaut? Das ist in 5 Minuten erledigt und funktioniert einfach. Über DynDNS-Adressen brauchst Du Dir dann keinen Kopf mehr zu machen...

Viele Grüße,
Jirka
root-ing
Beiträge: 5
Registriert: 21 Mai 2020, 11:27

Re: DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von root-ing »

GrandDixence hat geschrieben: 27 Mai 2020, 19:49 Sinnvoller und sicherer wäre es, wenn sich die Kunden per VPN-Tunnel zum internen Server verbinden. Ausser den Kunden muss niemand Zugriff auf diesen Server erhalten. Da IKEv2/IPSEC defacto "Industriestandard" ist, sollte das kein Problem sein...

Für VPN-Anleitungen siehe:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795
Hallo Jirka, das es mit VPN funktioniert und ich das auch schnell eingerichtet bekomme ist keine Frage.
Es ging mir hauptsächlich um das Probleme und das ich es nicht einfach mit dem Router ohne VPN lösen konnte.

Gegen VPN sprach - ohne es ausprobiert zu haben - das es sich um einen Backupjob mit viel Traffic handelt.
Bernd_k
Beiträge: 22
Registriert: 25 Apr 2019, 10:17

Re: DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von Bernd_k »

root-ing hat geschrieben: 27 Mai 2020, 15:46 Eine Suche hier im Forum zeigte schon das Lancom keine DNS Einträge (z.B. srvKunde1.no-ip.org) zur Definition bei den Stations-Objekten zu lässt.
Beim Ziel kann man doch DNS-Ziele/DNS-Listen definieren.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von Jirka »

Das ist richtig (ab LCOS 10.32), auch wenn DNS-Ziele nicht trivial umzusetzen sind. Bei ihm ist es aber die Quelle...
APu
Beiträge: 42
Registriert: 03 Mai 2006, 16:29

Re: DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von APu »

Hallo,

ich kenne das Problem und habe es in der Action-Tabelle gelöst:

Code: Alles auswählen

> l  /set/wan/act  @  +domain.name  +t-online

Index  Active  Host-Name    Peer           Lock-Time  Condition  Action                                            Check-For                 Owner  Routing-Tag
=======--------------------------------------------------------------------------------------------------------------------------------------------------------
51     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:getenv domainname_ip                                                   root   0
52     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  dnscheck:%h                                       isequal=%l?skipiftrue=3   root   0
53     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:setenv domainname_ip %l                                                root   0
54     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:getenv domainname_ip                                                   root   0
55     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:set  /set/ip-r/fir/ob/DOMAIN.NAME-IP %%A%l                             root   0
56     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  repeat:300                                                                  root   0
1. Vor LCOS10.32 habe ich das grundsätzlich so gemacht.
2. Trotz LCOS 10.32 brauche ich's immer noch für eingehende Verbindungen
und wenn es mehrere Aliase auf die gleiche IP gibt,
die nur die Anwendung kennt oder die ich nicht alle eintragen will.
3. Ins Flash wird nur geschieben, wenn sich der Wert ändert oder nach Cold-Boot.
4. Die Wiederholzeit im "repeat:300" kann ja nach Situation angepasst werden.

Mir fällt gerade auf:

Code: Alles auswählen

55     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:set  /set/ip-r/fir/ob/%h-IP %%A%l                                      root   0
wäre noch generischer, da ich aber den Hostnamen nicht direkt in den Umgebungsvariablen verwursten kann, lohnt das nicht und wird noch unleserlicher.

Gruß APu
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von Jirka »

Hallo,
APu hat geschrieben: 10 Jun 2020, 16:49 wäre noch generischer, da ich aber den Hostnamen nicht direkt in den Umgebungsvariablen verwursten kann, lohnt das nicht und wird noch unleserlicher.
das hängt aber vom Anwendungsfall ab, ob sich das lohnt oder nicht. Spätestens wenn Du das Script das erste mal kopierst und dann vergisst, da hinten auch den Namen zu ändern, hat es sich bereits gelohnt... Habe ich leider schon ab und an gehabt...

Viele Grüße,
Jirka
root-ing
Beiträge: 5
Registriert: 21 Mai 2020, 11:27

Re: DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von root-ing »

APu hat geschrieben: 10 Jun 2020, 16:49 Hallo,

ich kenne das Problem und habe es in der Action-Tabelle gelöst:

Code: Alles auswählen

> l  /set/wan/act  @  +domain.name  +t-online

Index  Active  Host-Name    Peer           Lock-Time  Condition  Action                                            Check-For                 Owner  Routing-Tag
=======--------------------------------------------------------------------------------------------------------------------------------------------------------
51     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:getenv domainname_ip                                                   root   0
52     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  dnscheck:%h                                       isequal=%l?skipiftrue=3   root   0
53     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:setenv domainname_ip %l                                                root   0
54     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:getenv domainname_ip                                                   root   0
55     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:set  /set/ip-r/fir/ob/DOMAIN.NAME-IP %%A%l                             root   0
56     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  repeat:300                                                                  root   0
1. Vor LCOS10.32 habe ich das grundsätzlich so gemacht.
2. Trotz LCOS 10.32 brauche ich's immer noch für eingehende Verbindungen
und wenn es mehrere Aliase auf die gleiche IP gibt,
die nur die Anwendung kennt oder die ich nicht alle eintragen will.
3. Ins Flash wird nur geschieben, wenn sich der Wert ändert oder nach Cold-Boot.
4. Die Wiederholzeit im "repeat:300" kann ja nach Situation angepasst werden.

Mir fällt gerade auf:

Code: Alles auswählen

55     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:set  /set/ip-r/fir/ob/%h-IP %%A%l                                      root   0
wäre noch generischer, da ich aber den Hostnamen nicht direkt in den Umgebungsvariablen verwursten kann, lohnt das nicht und wird noch unleserlicher.

Gruß APu
Hallo APu, hallo Jirka,

das ist natürlich eine richtig gute Lösung die ich gerade getestet habe und die auch funktioniert. Um irgendwann auch mal sowas "selbst" zu bauen habe ich zwei Fragen.

1. Wie kann ich die Aktionstabellen "debuggen" im Syslog steht dazu nichts und das wirkt für mich alles wie eine Blackbox. Jetzt könnte man sagen führe doch die Befehle auf der Shell aus. Stimmt. Aber bestimmte Teile des Codes sind nur innerhalb der Funktionstabellen (z.B. dnscheck) verfügbar. Ich würde mir das gerne einsehbarer Erarbeiten und wenn das nicht geht wenigstens ein Logfile oder eine Rückmeldung bekommen wollen.

2. Warum funktioniert das erst nach einem Neustart. Füge ich eine neue Aktion hinzu funtktioniert das nicht. Erst nach einem Neustart läuft das auch mit dem gewählten Update-Intervall.

P.S.: Die Bezeichnung aus dem Domainname automatisch zu übernehmen (siehe Code) ist zwar ganz nett und wie Jirka schreibt auch etwas "Copy&Paste" sicherer. ABER wenn der Domainname zu lang ist (war bei mit der Fall) wird die Station gar nicht angelegt (nur begrentze Zeichenfolge möglich). Auch das stand nirgends im Log. Habe ich nur durch "ausprobieren" hinbekommen.
Ich bevorzuge also lieber die feste Namensvergabe aus der ursprünglichen Code Version.

Code: Alles auswählen

55     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:set  /set/ip-r/fir/ob/%h-IP %%A%l                                      root   0
Vielen Dank für den ganzen Imput ich freu mich gerade das ich das direkt auf dem Lancom erledigen kann. Eine Fehlerquelle weniger ;-)
APu
Beiträge: 42
Registriert: 03 Mai 2006, 16:29

Re: DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von APu »

Guck mal unter

Code: Alles auswählen

l /st/wan/act/act
und mit

Code: Alles auswählen

tr # CONNACT
.

---

Wobei der LANtracer manchmal Probleme hat Tabelle "/st/wan/act/act" darzustellen oder danach,
wenn er den Inhalt dieser Tabelle mit Tabellenübeschriften verwechselt,
z.B. weil durch "l xyz" in Deinen Anweisungen auch Tabellenüberschriften in den Antworten sind.

Dann ist(war?) manchmal ein Schließen+Neuöffnen des LANtracer notwendig um wieder Synchron zu werden.

Das liegt daran, dass der LANtracer sehr generisch ist und vom aktuellen LCOS lernt, was gerade möglich ist,
wie breit Tabellenspalten sind, usw.

Gruß APu
APu
Beiträge: 42
Registriert: 03 Mai 2006, 16:29

Re: DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von APu »

root-ing hat geschrieben: 16 Jun 2020, 09:11 2. Warum funktioniert das erst nach einem Neustart. Füge ich eine neue Aktion hinzu funtktioniert das nicht. Erst nach einem Neustart läuft das auch mit dem gewählten Update-Intervall.
Trennen+Neuaufbauen der Verbindung (hier T-ONLINE-ADSL) sollte ausreichen.

Wenn ein Trigger ausgelöst wird, wird ein internes Script generiert, dass dann abläuft.
Wenn es repeat: enthält, wird der Trigger nach dieser Zeit nochmal ausgelöst, solange die die Verbindung noch besteht.

Achtung:
Jeder andere Trigger bricht das Script ab.
Die aktuelle Zeile wird jedoch noch zu Ende ausgeführt.
Deswegen ist es manchmal sinnvoll zwei Anweisungen bei exec: mit " ; " getrennt in eine Zeile zu schreiben.
root-ing hat geschrieben: 16 Jun 2020, 09:11 P.S.: Die Bezeichnung aus dem Domainname automatisch zu übernehmen (siehe Code) ist zwar ganz nett und wie Jirka schreibt auch etwas "Copy&Paste" sicherer. ABER wenn der Domainname zu lang ist (war bei mit der Fall) wird die Station gar nicht angelegt (nur begrentze Zeichenfolge möglich). Auch das stand nirgends im Log. Habe ich nur durch "ausprobieren" hinbekommen.
Ich bevorzuge also lieber die feste Namensvergabe aus der ursprünglichen Code Version.

Code: Alles auswählen

55     Yes     DOMAIN.NAME  T-ONLINE-ADSL  0          Establish  exec:set  /set/ip-r/fir/ob/%h-IP %%A%l                                      root   0
Das kam mir spontan beim Schreiben des Textes. Aber ich sah gleich, dass es nicht wie Jirka sagt viel
Copy'n'Paste Nutzen hat, da es nicht die einzige Stelle ist die fallspezifisch angepasst werden muss.
Und wenn ich den Namen des Firewall-Objektes im Klartext lese, hat das auch Vorteile für die Programmierung der Firewall.
Dann muss ich nicht soviel "blind" arbeiten. (;

Gruß APu
APu
Beiträge: 42
Registriert: 03 Mai 2006, 16:29

Re: DynDNS Server/PC als Stations-Objekt unter Firewall/QoS

Beitrag von APu »

Präzisierung:
Jeder andere Trigger bricht das Script ab.
Also: Jeder andere Trigger einer beliebigen(?) Verbindung, egal ob Aufbau oder Abbau, bricht das Script ab.

Frage, da noch nie gemacht:
Wie lange läuft ein repeat: in einem Aufbaufehler- oder einem Ende-Trigger?

Bei einem Aufbau-Trigger läuft ein Script durch repeat: solange wie dei Trigger-Bedingung bestehen bleibt
und nicht durch einen anderen Trigger verdrängt wird.
Wann ist die Trigger-Bedingung bei den anderen Triggern zu Ende?

Uups, wenn das so stimmt, dann würde mein obiges Script, bei mehreren Verbindungen
(eine davon Langläufer mit obigem Script, weitere mit andreren Scripten) abbrechen,
sobald diese Verbindungen auf- bzw. abgebaut werden, also deren Scripte ausgeführt werden.

Noch Klärungsbedarf.
Habe z.Zt. keine Zeit für solche Tests.

Vielleich liegt mein Denkfehler bei einer beliebigen Verbindung.
Vielleich passiert das Verdrängen des Triggers nur durch andere Trigger der gleichen Verbindung.

Kann man das obige Script für mehr als einen Domainnamen pro Verbindung nutzen?
a) Einmal ausführen wird sicher klappen,
b) jedoch das mit dem repeat: könnte irgendawann vor Verbindungsende aufhören.

Das ganze wird jetzt so speziell, das gehört vmtl. in einen eigenen Thread.

Gruß APu

PS: von wegen Präzisierung: ... (:

EDIT: obige PS: angehängt
Antworten