Beiträge von andreasbe

Hallo zusammen,

leider gelingt es mir nicht Sophos XG Home auf einer Netcup VM zu installieren.

Netcup sagt wohl immer, Ethernet 1 = WAN, alle weiteren für VLANs dann 2,3...

Sophos erwartet aber auf Port1 immer LAN

Im Rahmen des Setups kann man dort zwar die WAN IP festlegen (Advanced Shell - ifconfig), und das Basissetup durchführen (über Webinterface https://WAN-IP:4444), danach hat man sich aber ausgeschlossen ohne die Möglichkeit zu erhalten Port1 und Port2 innerhalb Sophos zu tauschen.

Ist es jemandem gelungen?

Ich bin dieser Anleitung gefolgt:

https://community.sophos.com/sophos-xg-firewall/f/discussions/127413/howto-setup-a-sophos-xg-on-netcup

Sie ist von 2021 und scheint nicht mehr zu funktionieren.

Viele Grüße und schönes Wochenende vorab

PS: Wenn Sophos nix wird, wird es halt pfsense, aber schön wäre es schon beim gleichen Produkt zu bleiben, was wir auch inhouse haben.

Zitat von mws92

Hallo,

ich habe mir vor kurzem zwei VPS 500 G10s gebucht. Auf einem habe ich eine Sophos XG Firewall installiert und dafür zusätzlich das kostenfreie vLAN 100MBit/s dazugebucht. Den zweiten vServer möchte ich jetzt als Mailserver einrichten und nur über das vLAN über die Firewall erreichbar machen.

Leider scheitere ich aktuell aber an der Netzwerkkonfiguration des zweiten Servers. Ich schaffe es zwar die IP Adresse statisch am vLAN Interface (eth1/ens4) einzutragen, allerdings bleibt mir die gesetzte Route, welche alles über das vLAN Interface zur Firewall routet nicht erhalten. Spätestens nach einem Neustart muss die Route wieder neu gesetzt werden, damit ich den Server über die "interne" IP erreichen kann.

Könnt Ihr mir weiterhelfen uns sagen, wie ich die Route fix gesetzt bekomme und auch das öffentliche Interface dauerhaft deaktivieren kann, damit der Server nur mehr über die Firewall erreichbar ist?

Liebe Grüße

Manuel

Alles anzeigen

Hi Manuel,

sag mal wie hast du das mit der Sophos XG hinbekommen?

Da Netcup immer Port1 für WAN festlegt, und Sophos da LAN haben will, ist es mir nicht gelungen.

Ich konnte zwar durch Eintrag der WAN IP auf Port1 das Webinterface erreichen und die Basiskonfig durchführen, nach Finalisierung der Installation ist das Web Interface aber nicht mehr erreichbar und ich kann die Ports nicht tauschen LAN / WAN.

Ich glaube mit den aktuellen Versionen geht es gar nicht mehr.

Rückmeldung:

Läuft wesentlich stabiler, leider weiterhin jedoch nicht ohne kleinere Störungen, wonach die Failover IP auf dem falschen Host landet und ein Zugriff nicht mehr möglich ist.

Daher teste ich jetzt folgendes Szenario

• Umschaltung weiterhin über keepalived notify master script
  (Für sich alleine problematisch, siehe Erklärung unten)
• Cron Job der jede Minute prüft
  • Bin ich der MASTER laut keepalived
  • Wenn ja, frage über die SOAP Schnittstelle ns1:getVServerIPs ob Netcup das genauso sieht
  • Wenn nein, sorge über die SOAP Schnitstelle ns1:changeIPRouting dass sich das ändert

Downtimes / Nicht Erreichbarkeit von 1 Minute kann ich akzeptieren.

Ich beobachte weiter. Es scheint als scheinen die Zeiten mit den Hängern genau die zu sein wo Datenbank Backups, externe Backups, etc. laufen

Es ist jedoch IMMER zu sehen, dass nach 1-2 Sekunden (manchmal sogar innnerhalb der selben Sekunde) wieder geswitcht wird. z.B.

===================================
Date:  12-Dec-2022 23:20:08
[INFO] Now Master

===================================
Date:  12-Dec-2022 23:20:08
[INFO] Now Backup

Problem ist, dass auf dem eigentlichen Master um 23:20:08 keine Änderung stattfand. Der o.g. Server machte sich also zum Master, was der eigentliche Master aber nicht mitbekam. Daher klappt natürlich auch die Umschaltung per SOAP API nicht mehr zurück auf den eigentlichen Master, da sie nie ausgeführt wurde.

Für den Master sah der letzte Eintrag nämlich so aus (10 Uhr ist wirklich 10 Uhr AM - 24 Format wurde geprüft)

===================================
Date:  12-Dec-2022 10:21:29
[INFO] Now Master

Ah cool, genau das wollte ich auch noch einführen, habe bereits entsprechende Skripte vorbereitet.

Also zusätzlich über Cron-Job prüfen ob die Failover IP assigned ist und dann ggf. das SOAP Routing Skript aufrufen.

Der Teil mit ns1:getVServerIPs hat mir noch gefehlt, werde mir da etwas basteln.

Witzig, dass man dann auf die gleichen Ideen kommt

Es muss halt eine 100% Lösung sein, weil sonst ist gegenüber "Single Point of Failure" Deployment nichts gewonnen.

Die Netcup-Kisten laufen ja eigentlich sehr stabil.

Bisherige Beobachtung:

Seit 8:xx Uhr läuft es tatsächlich stabil und hat nicht mehr gewechselt.

Werde es über's Wochenende beobachten

Schönes selbiges

Zitat von michaeleifel

Bitte,

was ist denn an dem CloudVLAN Produkt kompliziert?

Meinte keepalived

Aktuelle aktive Konfiguration für weitere Tests (und für bessere Lesbarkeit dieses Threads)

vrrp_instance VI_1 {
    state BACKUP

    interface eth1
    virtual_router_id 10
    priority 200 // Master, 150 - Slave1, 100 Slave2
    advert_int 2
    preempt_delay 30
    unicast_src_ip 192.168.200.120/24

        unicast_peer {
        192.168.200.100/24
        192.168.200.110/24
    }

    virtual_ipaddress {
        111.222.111.222/32 dev eth0
    }

     notify_master "/mnt/gv0/keepalived_notify.sh Master"
     notify_backup "/mnt/gv0/keepalived_notify.sh Backup"
     notify_fault "/mnt/gv0/keepalived_notify.sh Fault"

}

Beim Hochfahren meckert er noch diese Option an, ggf. wäre das noch sehr interessant

Zitat

NOTICE: setting config option max_auto_priority should result in better keepalived performance

  # The following options can be used if vrrp, checker or bfd  processes
           # are timing out. This can be seen by a backup vrrp instance becoming
           # master even when the master is still running, because the master or
           # backup system is too busy to process vrrp packets.
           # --
           # keepalived can, if it detects that it is not running sufficiently
           # soon after a timer should expire, increase its priority, first
           # of all switching to realtime scheduling, and if that is not
           # sufficient, it will then increase its realtime priority by one each
           # time it detects a further delay in running. If the event that realtime
           # scheduling is enabled, RLIMIT_RTTIME will be set, using the values for
           # {bfd,checker,vrrp}_rlimit_rttime (see below). These values may need
           # to be increased for slower processors.
           # --
           # To limit the maximum increased automatic priority, specify the following
           # (0 doesn't use automatic priority increases, and is the default. -1 disables
           # the warning message at startup). Omitting the priority sets the maximum value.
           max_auto_priority [<-1 to 99>]  # 99 is really sched_get_priority_max(SCHED_RR)

Die Frage ist nur: Welchen Wert wählt man hier?

Theoretisch ist das beschriebene genau das was hier passieren könnte: Der Master ist durch Backups, Uploads etc zu ausgelastet um die Paket zu verarbeiten.
Backups werden dann zu Master, obwohl der Master eigentlich noch läuft...

Zitat von michaeleifel

Hallo,

Paul hat schon ein paar gute Ideen in den Raum geworfen.

Zu deiner Konfig hab ich paar Fragen:
1) Ich sehe keinerlei Konfiguration für Healthchecks von Diensten beispielsweise, ist das so gewollt?

2) Authentication kannst dir glaub sparen, so lese ich zumindest die Notiz:

Code

# Note: authentication was removed from the VRRPv2 specification by RFC3768 in 2004.

3) Warum nimmst du explizit unicast? Das ist meines Wissens nach bei Netcup nicht notwendig

Gibt es eine Node bei dir welche state Master hat?

Gruß

Alles anzeigen

Hi,

dir auch danke

1) ja bisher schon, stehe noch ganz am Anfang und wollte erst mal das Election-Verhalten beobachten und das switchen der Failover-IP bzw. Routing über das SOAP Skript. Leider klappt das wegen dem schnellen Wechsel noch nicht.

2) Danke ist raus

3) Mangels besseren Wissens? Ich finde das Produkt sehr kompliziert
Geht das über cloud vlan free oder müsste ich hier noch eine Spezialkonfiguration vornehmen?

4) Nein, alle starten mit Backup, es übernimmt dann automatisch der mit der höchsten Priorität

 # Initial state, MASTER|BACKUP
           # If the priority is 255, then the instance will transition immediately
           # to MASTER if state MASTER is specified; otherwise the instance will
           # wait between 3 and 4 advert intervals before it can transition,
           # depending on the priority.
           state MASTER

Scheint nur das Startverhalten zu beeinflussen

Zitat von Paul

Wie oft passiert das denn? Kannst du mal im VLAN einen Ping laufen lassen? Läuft das Monitoring ebenfalls über das VLAN?

Ansonsten ist

Code

advert_int 1

zwar der Default Wert, aber natürlich schon etwas aggressiv. Man könnte zum Test das auch mal etwas erhöhen. Ich stelle das meistens auf 2-3. Reicht ja eigentlich auch. Auch gibt es hier noch Optionen wie

Code

preempt_delay

welcher dafür sorgt, dass nicht zu schnell wieder zurück geschwenkt wird. Das ist vor allem in Verbindung mit der SOAP API wichtig, da ein Umschalten immer eine gewisse Zeit braucht. Wenn keepalived wieder zurückschalten will, aber das Umschalten noch nicht fertig ist, hat der falsche Master die Failover IP und nichts geht mehr. Da muss man etwas aufpassen. Ich würde preemt_delay daher immer mindestens auf 30 setzen.

Hi,

danke für die Rückmeldung

es passiert ca. alle 5-7 Stunden.

Die oberen beiden Werte habe ich angepasst.

Ebenso die Priority mal wie vorgeschlagen mindestens auf 50 Abstand konfiguriert

priority 

To be MASTER, it is recommended to make this 50 more than on
           # other machines. All systems should have different priorities

Also gewünschter Master 200, nächster 150, dritter 100

Das Monitoring läuft über Zabbix Checks von einem externen Host über die public IP (Passive Checks)

Kurzen Schluckauf bekomme ich darüber nicht mit, aber längeres Ausbleiben des Agents. Aber ich glaube das Problem hier ist maximal kurzer temporärer Schluckauf.

zu

Master_Down_Interval

finde ich leider in der Doku (https://www.keepalived.org/manpage.html) nichts.

Ein Ping im VLAN läuft ohne Aussetzer durch. Ich müsste mir aber vermutlich ein Skript bauen welches die (möglichen) Aussetzer loggt, aber wenn man eine zeitlang zuschaut geht es ohne ein Paket Verlust.

Hallo zusammen

ich habe 3 netcup Server über cloud vlan free miteinander verbunden.

Die Betriebssysteme sind

• Server 1 Ubuntu 18.x LTS (im vlan 192.168.200.100/24)
• Server 2 Ubuntu 20.x LTS (im vlan 192.168.200.110/24)
• Server 3 Ubuntu 22.x LTS (im vlan 192.168.200.120/24)

Auf allen habe ich keepalived aus den sourcen installiert, da die Versionen sonst zu unterschiedlich gewesen wären (aus den apt Paketquellen)

Hierfür habe ich Version keepalived-2.2.4 gewählt

(https://www.keepalived.org/software/keepalived-2.2.4.tar.gz)

keepalived wurde auf allen nodes folgendermaßen konfiguriert

Failover IP exemplarisch 111.222.111.222/32

vrrp_instance VI_1 {
    state BACKUP

    interface eth1
    virtual_router_id 10
    priority 170
    advert_int 1

    unicast_src_ip 192.168.200.100/24 // Server 1 im vlan
    
    unicast_peer {
        192.168.200.110/24 // Server 2 im vlan
        192.168.200.120/24 // Server 3 im vlan
    }

    virtual_ipaddress {
        111.222.111.222/32 dev eth0
    }

    authentication {
        auth_type PASS
        auth_pass MYPASS
    }


    notify_master "/root/scripts/keepalived_notify.sh Master"
    notify_backup "/root/scripts/keepalived_notify.sh Backup"
    notify_fault "/root/scripts/keepalived_notify.sh Fault"

}

Die Idee ist damit später per SOAP-API die Failover IP nach dem Skript aus https://forum.netcup.de/netcup-anwendu…oninterfacemac/ umzuschalten.

Allerdings ist die Master-Wahl noch viel zu wackelig. Ohne erkennbaren Grund kommt es zu Wechseln wie diesem

Hier aus Sicht von Server 2, der eine niedrigere Priorität als Server 1 hat und daher BACKUP sein müsste (statt MASTER)

Zitat

Date: 08-Dec-2022 13:08:56

[INFO] Now Master

===================================

Date: 08-Dec-2022 13:10:22

[INFO] Now Backup

===================================

Date: 08-Dec-2022 13:10:25

[INFO] Now Master

===================================

Date: 08-Dec-2022 13:11:15

[INFO] Now Backup

Alles anzeigen

Server1 war zu jederzeit erreichbar und das Monitoring (Zabbix) meldet keine Ausfälle. Zudem war ich jederzeit per ssh verbunden ohne Abbrüche

Hat jemand eine Idee wie man das stabiler bekommt? Ich würde das SOAP-Script zum Failover-IP-Routing erst aktivieren, wenn das stabil ist

Besten Dank vorab!

Hallo,

ich bin heute über diesen Thread gestolpert.

Ich wollte nur kurz Rückmeldung geben, dass es mit dem Skript https://git.com.de/LibertaCasa/sy…cup_failover.sh einwandfrei funktioniert. Danke dafür!

Die Einrichtung ist noch frisch bei mir, wer Fragen hat, bitte frei heraus!

Wichtig ist im SCP den Webservice zu aktivieren und ein Passwort zu erstellen, es funktioniert NICHT mit dem SCP Web-Login Passwort!

Gruß Andreas