zeitgesteuerte NAT Regel / per Skript / per ssh



  • Hallo Forum,
    ich habe hinter einer (es sind eigentlich mehrere Standorte mit je einer) pfSense mehrere Server die sich alle zeitgesteuert schön selber ihre LetsEncrypt Zertifikate holen sollen und die dann bei sich einpflegen. Mir gehen nur grad die praktikablen Ideen aus das umzusetzen.

    Ideal wäre es wenn ich auf der pfSense selber zeitgesteuert (z.B. 1x die Woche nachts für einen kurzen Zeitraum) jeweils eine NAT Regel aktiviere und das für jeden Webserver halt immer ein anderes Weiterleitungsziel von Port 80. Notfalls kann ich das auch von den jew. Server selber per ssh Einwahl auf die pfSense ausführen lassen - aber ich habe noch keine elegante Möglichkeit gefunden das per Skript lokal oder von extern zu lösen. Ich möchte auch nicht dauerhaft Port 80 irgendwohin freigeben. Die Firewall Regel kann ich mit einem Scheduler versehen, die NAT Regel und damit das Weiterleitungsziel aber nicht. Welche Möglichkeiten habe ich noch das zu realisieren?

    Hinweis: die Standorte haben tlw. keine feste IP, die den (tlw. verschiedenen) Domänen zugehörigen externen Nameserver kann ich i.d.R. nur über ein Webinterface konfigurieren und somit fällt die TXT Record Lösung im Prinzip schon mal aus. FTP Upload zu einem der Domain zugehörigen Webspace fällt tlw. auch aus, auch keine Lösung. Es bleibt mir nur die Lösung mit int. Webserver für den Vorgang der Rezertifizierung und damit unterschiedliche NAT Regeln für Port 80.


  • Banned

    Am besten HAProxy nutzen und darüber die Zertifikate laufen lassen.



  • Frage: HAProxy schließt gleichzeitige squid Installation und Nutzung aus?



  • @bon-go
    Du könntest auf den Servern UPnP nutzen, um die Port-Weiterleitung bei Bedarf zu schalten, und es auf der Firewall entsprechend konfigurieren.



  • Das ist keine Option.


  • LAYER 8 Rebel Alliance

    Wenn dein DNS Provider RFC 2136 kennt und kann oder eine Lets Encrypt API hat wäre das die eleganteste Lösung.
    Mal gemütlich das Hangout von Jim bei einer Tasse Kaffee angeschaut? :-) https://www.netgate.com/resources/videos/lets-encrypt-on-pfsense.html
    Evtl. kannst du da noch einen Tipp mitnehmen der bei deiner Konstellation weiter hilft.

    -Rico



  • Kein RFC2136, kein API. Irgendwann vielleicht. Die Hoffnung stirbt zuletzt.
    Hab das Video noch nicht gekannt, danke für den Tip. Vorwärts bis 54m gezappt weil bis dahin nichts anwendbar / bereits bekannt. Hab mir das mit HAProxy angeschaut. Muss ich drüber nachdenken, sind eben auch verschiedene Szenarien.

    Ich brauche in den meisten Fällen die Zertifikate auch direkt auf den Maschinen dahinter. Daher wäre das Initiieren des Requests von der betreffenden Maschine selber der bessere Weg. Zu diesem Zeitpunkt muss es halt eine NAT Regel dafür geben - oder eben einen Reverse Proxy der entspr. der ext. Anfrage weiterleitet. Denke ich drüber nach.



  • Moin,

    was sich bei uns als praktikabel erwiesen hat:

    • Die pf holt via acme die Zertifikate und legt sie zur weiterverteilung lokal ab
    • Im Nachgang werden die Zertifikate über scripts von der pf via scp verteilt und die deamons via ssh neu gestartet
    • scp / ssh Anmeldung natürlich ohne Passwort sondern via PKI

    HornetX11

    Mobil



  • Zurück zu meiner Frage: HAProxy schließt gleichzeitige squid Installation und Nutzung aus?


  • LAYER 8 Moderator

    Acme Package hat die Möglichkeit die geholten Zertifikate auf der Sense im entsprechenden Ordner zusätzlich zu speichern - nicht nur im Cert-Manager. Damit könnten alle zentral auf der Sense geholt werden. Müsste man lediglich stumpf einen SSH/SFTP Only User anlegen, mit dem man von anderen Servern sich kurz 1x im Monat das aktuelle Zertifikat holt und einspielt. Ist jetzt keine riesige Angelegenheit. Ansonsten sind DNS01 wenn möglich (anscheinend nicht) oder Proxy vorgeschaltet natürlich auch Möglichkeiten.



  • Ich habe das mit haproxy gelöst, sehr schön, danke nochmal für die Idee. Die notwendige Regel zum öffnen des Ports 80 kann ich so auch zeitgesteuert ein- und ausschalten. Gibt auch bisher kein Problem mit einem evtl. parallel laufendem squid.


Log in to reply