Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
fbtr64toolbox: Port enable für ein anderes Gerät?
7 views
Skip to first unread message
Rolf Bensch
Jan 7, 2024, 7:03:59 AM1/7/24
to
Hallo zusammen,
auf dem Client 192.168.0.206 versuche ich auf der Fritzbox für den Client ...207 eine Portfreigabe per Script einzurichten.
# fbtr64toolbox.sh enable --extport 80 --protocol TCP --intclient 192.168.0.207 --intport 80 --description "LE-Test" --verbose
Enable port forwarding (FRITZ!Box 7590 AX Release 259....@192.168.0.1)
Error on communication with fritzbox
Return codes of TR-064 function calls
tr64desc.xml;deviceinfo;DeviceInfo:1;GetSecurityPort: ok
tr64desc.xml;deviceinfo;DeviceInfo:1;GetInfo: ok
tr64desc.xml;wanpppconn1;WANPPPConnection:1;GetInfo: ok
tr64desc.xml;wanpppconn1;WANPPPConnection:1;AddPortMapping: 600 Argument Value Invalid
------------------------------------------------------------------
Device : FRITZ!Box 7590 AX Release 259....@192.168.0.1
Command line : enable --extport 80 --protocol TCP --intclient 192.168.0.207 --intport 80 --description LE-Test --verbose
Auth method : user/password
Script version: 3.2.9
Errorlevel : 1
Errorcode : Error on communication with fritzbox
------------------------------------------------------------------
Use --debugfb option to retrieve more informations.
Wenn ich das für die eigene IP (...206) einrichte, funktioniert das tadellos. Soll das so sein? War das schon immer so? Ich meine früher konnte man eine beliebige (bereits eingerichtete) Portfreigabe auf der Fritzbox aktivieren/deaktivieren.
Grüße
Rolf
auf dem Client 192.168.0.206 versuche ich auf der Fritzbox für den Client ...207 eine Portfreigabe per Script einzurichten.
# fbtr64toolbox.sh enable --extport 80 --protocol TCP --intclient 192.168.0.207 --intport 80 --description "LE-Test" --verbose
Enable port forwarding (FRITZ!Box 7590 AX Release 259....@192.168.0.1)
Error on communication with fritzbox
Return codes of TR-064 function calls
tr64desc.xml;deviceinfo;DeviceInfo:1;GetSecurityPort: ok
tr64desc.xml;deviceinfo;DeviceInfo:1;GetInfo: ok
tr64desc.xml;wanpppconn1;WANPPPConnection:1;GetInfo: ok
tr64desc.xml;wanpppconn1;WANPPPConnection:1;AddPortMapping: 600 Argument Value Invalid
------------------------------------------------------------------
Device : FRITZ!Box 7590 AX Release 259....@192.168.0.1
Command line : enable --extport 80 --protocol TCP --intclient 192.168.0.207 --intport 80 --description LE-Test --verbose
Auth method : user/password
Script version: 3.2.9
Errorlevel : 1
Errorcode : Error on communication with fritzbox
------------------------------------------------------------------
Use --debugfb option to retrieve more informations.
Wenn ich das für die eigene IP (...206) einrichte, funktioniert das tadellos. Soll das so sein? War das schon immer so? Ich meine früher konnte man eine beliebige (bereits eingerichtete) Portfreigabe auf der Fritzbox aktivieren/deaktivieren.
Grüße
Rolf
Marcus Röckrath
Jan 7, 2024, 8:30:03 AM1/7/24
to
Hallo Rolf,
Rolf Bensch wrote:
> auf dem Client 192.168.0.206 versuche ich auf der Fritzbox für den Client
> ...207 eine Portfreigabe per Script einzurichten.
>
> # fbtr64toolbox.sh enable --extport 80 --protocol TCP --intclient
> # 192.168.0.207 --intport 80 --description "LE-Test" --verbose
sich selbst bearbeiten/anlegen/löschen.
Das ist eine Einschränkung, die AVM irgendwie um Firmware 6.9/7 eingeführt
hat.
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch wrote:
> auf dem Client 192.168.0.206 versuche ich auf der Fritzbox für den Client
> ...207 eine Portfreigabe per Script einzurichten.
>
> # fbtr64toolbox.sh enable --extport 80 --protocol TCP --intclient
> Enable port forwarding (FRITZ!Box 7590 AX Release
> 259....@192.168.0.1) Error on communication with fritzbox
>
> Return codes of TR-064 function calls
> tr64desc.xml;deviceinfo;DeviceInfo:1;GetSecurityPort: ok
> tr64desc.xml;deviceinfo;DeviceInfo:1;GetInfo: ok
> tr64desc.xml;wanpppconn1;WANPPPConnection:1;GetInfo: ok
> tr64desc.xml;wanpppconn1;WANPPPConnection:1;AddPortMapping: 600
> Argument Value Invalid
> ------------------------------------------------------------------
> Device : FRITZ!Box 7590 AX Release 259....@192.168.0.1
> Command line : enable --extport 80 --protocol TCP --intclient
> 192.168.0.207 --intport 80 --description LE-Test --verbose
> Auth method : user/password
> Script version: 3.2.9
> Errorlevel : 1
> Errorcode : Error on communication with fritzbox
> ------------------------------------------------------------------
> Use --debugfb option to retrieve more informations.
>
> Wenn ich das für die eigene IP (...206) einrichte, funktioniert das
> tadellos. Soll das so sein? War das schon immer so? Ich meine früher
> konnte man eine beliebige (bereits eingerichtete) Portfreigabe auf der
> Fritzbox aktivieren/deaktivieren.
Das ging mal; inzwischen dürfen Clients nur noch Portweiterleitungen für
> 259....@192.168.0.1) Error on communication with fritzbox
>
> Return codes of TR-064 function calls
> tr64desc.xml;deviceinfo;DeviceInfo:1;GetSecurityPort: ok
> tr64desc.xml;deviceinfo;DeviceInfo:1;GetInfo: ok
> tr64desc.xml;wanpppconn1;WANPPPConnection:1;GetInfo: ok
> tr64desc.xml;wanpppconn1;WANPPPConnection:1;AddPortMapping: 600
> Argument Value Invalid
> ------------------------------------------------------------------
> Device : FRITZ!Box 7590 AX Release 259....@192.168.0.1
> Command line : enable --extport 80 --protocol TCP --intclient
> 192.168.0.207 --intport 80 --description LE-Test --verbose
> Auth method : user/password
> Script version: 3.2.9
> Errorlevel : 1
> Errorcode : Error on communication with fritzbox
> ------------------------------------------------------------------
> Use --debugfb option to retrieve more informations.
>
> Wenn ich das für die eigene IP (...206) einrichte, funktioniert das
> tadellos. Soll das so sein? War das schon immer so? Ich meine früher
> konnte man eine beliebige (bereits eingerichtete) Portfreigabe auf der
> Fritzbox aktivieren/deaktivieren.
sich selbst bearbeiten/anlegen/löschen.
Das ist eine Einschränkung, die AVM irgendwie um Firmware 6.9/7 eingeführt
hat.
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
Jan 7, 2024, 10:15:53 AM1/7/24
to
Hallo Marcus,
Am 07.01.24 um 14:26 schrieb Marcus Röckrath:
Hmmm. "show" zeigt noch alle Freigaben, steuern oder modifizieren kann man nur für die eigene Ressource. Der Sinn erschließt sich mir nicht wirklich. Wenn man hier etwas "schützen" möchte, wäre es vermutlich sinnvoller, _eine_ Ressource explizit zu berechtigen anstatt alle die dann auch, jede für sich, z.B. eine Freigang auf Port 80 anfordern können - vielleicht ist sie ja gerade frei. Manchmal sind die Denk-Strukturen bei AVM nur schwer nachvollziehbar.
Grüße
Rolf
Am 07.01.24 um 14:26 schrieb Marcus Röckrath:
Grüße
Rolf
Marcus Röckrath
Jan 7, 2024, 10:40:04 AM1/7/24
to
Hallo Rolf,
Rolf Bensch wrote:
> Hmmm. "show" zeigt noch alle Freigaben, steuern oder modifizieren kann man
> nur für die eigene Ressource.
So will es AVM.
Rolf Bensch wrote:
> Hmmm. "show" zeigt noch alle Freigaben, steuern oder modifizieren kann man
> nur für die eigene Ressource.
Übrigens hat die Sache auch einen weiteren Haken: Eine per TR64 angelegte
Portweiterleitung sollte man nicht mehr per TR64 löschen, sondern nur
deaktivieren (und bei Bedarf wieder aktivieren).
> Der Sinn erschließt sich mir nicht wirklich.
Als Netzadmin arbeite ich zentral auf einer Adminmaschine, um ein Netz zu
"registrieren".
Man kann da eventuell tricksen, wenn man alle Portforwarding zunächst auf
einer Maschine auflaufen lässt und dann dort selbst mittels socat an die
gewollte Zielmaschine weiterleitet.
Habs aber nicht getestet und begeistern würde mich solches Gehampel auch
nicht.
Was ist dein .207?
Kannst du da nicht auch fbtr64toolbox nutzen?
Das Teil läuft grundsätzlich unter beliebigen Linux-Distris und im WSL von
Windows.
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
Jan 7, 2024, 11:28:42 AM1/7/24
to
Hallo Marcus,
Am 07.01.24 um 16:32 schrieb Marcus Röckrath:
> Was ist dein .207?
Eis-Mailserver. Auf dem .206 läuft der Eis-Apache.
> Kannst du da nicht auch fbtr64toolbox nutzen?
Das mache ich bereits. Wenn jetzt aber auf dem Mailserver dehydrated aktualisieren will, darf auf dem Apache Port 80 nicht mehr aktiv sein. Die Idee war jetzt zuvor mit fbtr64toolbox den Port 80 für den .206 zu disablen und dann auf dem .207 zu enablen - und das möglichst innerhalb _eines_ Script.
Grüße
Rolf
Am 07.01.24 um 16:32 schrieb Marcus Röckrath:
> Man kann da eventuell tricksen, wenn man alle Portforwarding zunächst auf
> einer Maschine auflaufen lässt und dann dort selbst mittels socat an die
> gewollte Zielmaschine weiterleitet.
>
> Habs aber nicht getestet und begeistern würde mich solches Gehampel auch
> nicht.
>
das halte auch ich für wenig praktikabel.
> einer Maschine auflaufen lässt und dann dort selbst mittels socat an die
> gewollte Zielmaschine weiterleitet.
>
> Habs aber nicht getestet und begeistern würde mich solches Gehampel auch
> nicht.
>
> Was ist dein .207?
Eis-Mailserver. Auf dem .206 läuft der Eis-Apache.
> Kannst du da nicht auch fbtr64toolbox nutzen?
Grüße
Rolf
Marcus Röckrath
Jan 7, 2024, 12:20:04 PM1/7/24
to
Hallo Rolf,
Rolf Bensch wrote:
Rolf Bensch wrote:
>> Was ist dein .207?
>
> Eis-Mailserver. Auf dem .206 läuft der Eis-Apache.
>
>> Kannst du da nicht auch fbtr64toolbox nutzen?
>
> Das mache ich bereits. Wenn jetzt aber auf dem Mailserver dehydrated
> aktualisieren will, darf auf dem Apache Port 80 nicht mehr aktiv sein. Die
> Idee war jetzt zuvor mit fbtr64toolbox den Port 80 für den .206 zu
> disablen und dann auf dem .207 zu enablen - und das möglichst innerhalb
> _eines_ Script.
Nach außen sind die doch erstmal unter einer FQDN sichtbar. Wieso dann
>
> Eis-Mailserver. Auf dem .206 läuft der Eis-Apache.
>
>> Kannst du da nicht auch fbtr64toolbox nutzen?
>
> Das mache ich bereits. Wenn jetzt aber auf dem Mailserver dehydrated
> aktualisieren will, darf auf dem Apache Port 80 nicht mehr aktiv sein. Die
> Idee war jetzt zuvor mit fbtr64toolbox den Port 80 für den .206 zu
> disablen und dann auf dem .207 zu enablen - und das möglichst innerhalb
> _eines_ Script.
überhaupt auf beiden unterschiedliche letsencrypt-Zertifikate?
Macht das für einen externen "Besucher" des Mail- oder Webservers nicht eher
Probleme, wenn er verschiedene Zertifikate für die gleiche Domain
vorgesetzt bekommt?
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
Jan 8, 2024, 3:08:01 AM1/8/24
to
Hallo Marcus,
Am 07.01.24 um 18:13 schrieb Marcus Röckrath:
> Macht das für einen externen "Besucher" des Mail- oder Webservers nicht eher
> Probleme, wenn er verschiedene Zertifikate für die gleiche Domain
> vorgesetzt bekommt?
Das passiert hier nicht.
Was könnte ich verbessern? Kürzlich las ich hier in der Gruppe, dass mittlerweile Wildcard-Zertifikate bei Letsencrypt möglich sind. Wie müsste man das konfigurieren? Wie bekomme ich dann das Zertifikat auf den anderen Server? Einfach mit "scp ...206/usrl/local/ssl/certs/apache.pem ...207/usr/local/ssl/certs/exim.pem"?
Grüße
Rolf
Am 07.01.24 um 18:13 schrieb Marcus Röckrath:
> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>>> Was ist dein .207?
>>
>> Eis-Mailserver. Auf dem .206 läuft der Eis-Apache.
>>
>>> Kannst du da nicht auch fbtr64toolbox nutzen?
>>
>> Das mache ich bereits. Wenn jetzt aber auf dem Mailserver dehydrated
>> aktualisieren will, darf auf dem Apache Port 80 nicht mehr aktiv sein. Die
>> Idee war jetzt zuvor mit fbtr64toolbox den Port 80 für den .206 zu
>> disablen und dann auf dem .207 zu enablen - und das möglichst innerhalb
>> _eines_ Script.
>
> Nach außen sind die doch erstmal unter einer FQDN sichtbar. Wieso dann
> überhaupt auf beiden unterschiedliche letsencrypt-Zertifikate?
Die Zertifikate werden aktuell auf Sub-Domains ausgestellt.
>
> Rolf Bensch wrote:
>
>>> Was ist dein .207?
>>
>> Eis-Mailserver. Auf dem .206 läuft der Eis-Apache.
>>
>>> Kannst du da nicht auch fbtr64toolbox nutzen?
>>
>> Das mache ich bereits. Wenn jetzt aber auf dem Mailserver dehydrated
>> aktualisieren will, darf auf dem Apache Port 80 nicht mehr aktiv sein. Die
>> Idee war jetzt zuvor mit fbtr64toolbox den Port 80 für den .206 zu
>> disablen und dann auf dem .207 zu enablen - und das möglichst innerhalb
>> _eines_ Script.
>
> Nach außen sind die doch erstmal unter einer FQDN sichtbar. Wieso dann
> überhaupt auf beiden unterschiedliche letsencrypt-Zertifikate?
> Macht das für einen externen "Besucher" des Mail- oder Webservers nicht eher
> Probleme, wenn er verschiedene Zertifikate für die gleiche Domain
> vorgesetzt bekommt?
Was könnte ich verbessern? Kürzlich las ich hier in der Gruppe, dass mittlerweile Wildcard-Zertifikate bei Letsencrypt möglich sind. Wie müsste man das konfigurieren? Wie bekomme ich dann das Zertifikat auf den anderen Server? Einfach mit "scp ...206/usrl/local/ssl/certs/apache.pem ...207/usr/local/ssl/certs/exim.pem"?
Grüße
Rolf
Marcus Röckrath
Jan 8, 2024, 3:50:03 AM1/8/24
to
Hallo Rolf,
Rolf Bensch wrote:
> Die Zertifikate werden aktuell auf Sub-Domains ausgestellt.
>
>> Macht das für einen externen "Besucher" des Mail- oder Webservers nicht
>> eher Probleme, wenn er verschiedene Zertifikate für die gleiche Domain
>> vorgesetzt bekommt?
>
> Das passiert hier nicht.
>
> Was könnte ich verbessern? Kürzlich las ich hier in der Gruppe, dass
> mittlerweile Wildcard-Zertifikate bei Letsencrypt möglich sind.
Ich nutze selbst letsencrypt nicht, aber Wildcard geht über
Rolf Bensch wrote:
> Die Zertifikate werden aktuell auf Sub-Domains ausgestellt.
>
>> Macht das für einen externen "Besucher" des Mail- oder Webservers nicht
>> eher Probleme, wenn er verschiedene Zertifikate für die gleiche Domain
>> vorgesetzt bekommt?
>
> Das passiert hier nicht.
>
> Was könnte ich verbessern? Kürzlich las ich hier in der Gruppe, dass
> mittlerweile Wildcard-Zertifikate bei Letsencrypt möglich sind.
DEHYDRATED_DOMAIN_1_NAME='domain.de:*.domain.de:domain.de'
Dass domain.de hier doppelt auftaucht, ist IMHO normal und richtig, da dem
Wildcard immer noch ein nicht Wildcardalias folgen muss.
Im Thread "certs_dehydrated Wildcard-Zertifikat" wurde das mal diskutiert.
> Wie müsste
> man das konfigurieren? Wie bekomme ich dann das Zertifikat auf den anderen
> Server? Einfach mit "scp ...206/usrl/local/ssl/certs/apache.pem
> ...207/usr/local/ssl/certs/exim.pem"?
letsencrypt-Zertifikat IMHO unter dem Domainnamen des Serveres angelegt,
welche Dateien alle genau da angelegt werden, kann ich so nicht sagen.
apache.pem und Co sollten in der Regel Symlinks auf das physische
letencrypt-Zertifikat sein.
Wenn man alle notwendigen Dateinen auf den zweiten Server überträgt, was mit
scp erfolgen kann (rehashen nicht vergessen), sollte es auch auf dem
anderen Server funktionieren.
Vielleicht kann da Jürgen (Edner) noch etwas Klarheit reinbringen.
--
Gruß Marcus
[eisfair-Team]
Rolf Bensch
Jan 8, 2024, 11:02:41 AM1/8/24
to
Hallo Marcus,
Am 08.01.24 um 09:42 schrieb Marcus Röckrath:
> Dass domain.de hier doppelt auftaucht, ist IMHO normal und richtig, da dem
> Wildcard immer noch ein nicht Wildcardalias folgen muss.
>
> Im Thread "certs_dehydrated Wildcard-Zertifikat" wurde das mal diskutiert.
Der Thread lief Anfang November ohne belastbares Ergebnis. Letztendlich ging es aber um die Syntax des Parameter "DEHYDRATED_DOMAIN_1_NAME". Es wurde beschrieben, dass die von Dir vorgeschlagene Syntax funktioniert. Meine dehydrated-Version ist vom August, also ist aus dem Thread (bisher) keine Änderung am Paket hervorgegangen. Vielleicht ist das auch nicht notwendig.
Grüße
Rolf
Am 08.01.24 um 09:42 schrieb Marcus Röckrath:
> Hallo Rolf,
>
> Rolf Bensch wrote:
>
>> Die Zertifikate werden aktuell auf Sub-Domains ausgestellt.
>>
>>> Macht das für einen externen "Besucher" des Mail- oder Webservers nicht
>>> eher Probleme, wenn er verschiedene Zertifikate für die gleiche Domain
>>> vorgesetzt bekommt?
>>
>> Das passiert hier nicht.
>>
>> Was könnte ich verbessern? Kürzlich las ich hier in der Gruppe, dass
>> mittlerweile Wildcard-Zertifikate bei Letsencrypt möglich sind.
>
> Ich nutze selbst letsencrypt nicht, aber Wildcard geht über
>
> DEHYDRATED_DOMAIN_1_NAME='domain.de:*.domain.de:domain.de'
Das läuft hier leider noch nicht rund. Ich mache dazu mal einen eigenen Thread auf.
>
> Rolf Bensch wrote:
>
>> Die Zertifikate werden aktuell auf Sub-Domains ausgestellt.
>>
>>> Macht das für einen externen "Besucher" des Mail- oder Webservers nicht
>>> eher Probleme, wenn er verschiedene Zertifikate für die gleiche Domain
>>> vorgesetzt bekommt?
>>
>> Das passiert hier nicht.
>>
>> Was könnte ich verbessern? Kürzlich las ich hier in der Gruppe, dass
>> mittlerweile Wildcard-Zertifikate bei Letsencrypt möglich sind.
>
> Ich nutze selbst letsencrypt nicht, aber Wildcard geht über
>
> DEHYDRATED_DOMAIN_1_NAME='domain.de:*.domain.de:domain.de'
> Dass domain.de hier doppelt auftaucht, ist IMHO normal und richtig, da dem
> Wildcard immer noch ein nicht Wildcardalias folgen muss.
>
> Im Thread "certs_dehydrated Wildcard-Zertifikat" wurde das mal diskutiert.
Grüße
Rolf
Marcus Röckrath
Jan 8, 2024, 11:20:03 AM1/8/24
to
Hallo Rolf,
Rolf Bensch wrote:
>> DEHYDRATED_DOMAIN_1_NAME='domain.de:*.domain.de:domain.de'
Rolf Bensch wrote:
>
>> Dass domain.de hier doppelt auftaucht, ist IMHO normal und richtig, da
>> dem Wildcard immer noch ein nicht Wildcardalias folgen muss.
>>
>> Im Thread "certs_dehydrated Wildcard-Zertifikat" wurde das mal
>> diskutiert.
>
> Der Thread lief Anfang November ohne belastbares Ergebnis. Letztendlich
> ging es aber um die Syntax des Parameter "DEHYDRATED_DOMAIN_1_NAME".
Genau; es wurde bemängelt, dass im Zertifikatsprozess durch die notwendige
>> Dass domain.de hier doppelt auftaucht, ist IMHO normal und richtig, da
>> dem Wildcard immer noch ein nicht Wildcardalias folgen muss.
>>
>> Im Thread "certs_dehydrated Wildcard-Zertifikat" wurde das mal
>> diskutiert.
>
> Der Thread lief Anfang November ohne belastbares Ergebnis. Letztendlich
> ging es aber um die Syntax des Parameter "DEHYDRATED_DOMAIN_1_NAME".
Festlegung obiger Option etwas doppelt gemoppelt durchgeführt wird, was
unschön aber nicht problematisch ist.
Ich wollte nur deshalb auf diesen Thread hinweisen, damit die etwas
ungewöhnliche Konfiguration mit dem doppelt auftretenden Part bestätigt
ist.
--
Gruß Marcus
[eisfair-Team]
0 new messages