Beiträge von michaeleifel

Verstehe ich es richtig, dass bei dem CNAME der redirect nicht funktioniert?

Durch den CNAME hat ja dein Webhosting nichts mehr damit zu tun, sprich du musst auf dem CNAME Ziel den HTTPS Redirect konfigurieren.

Zitat von txxt

Ich habe eben festgestellt, dass die netcup nameserver (die ersten drei von https://www.netcup-wiki.de/wiki/Nameserver) teilweise 5 oder 10 Sekunden Wartezeiten vor einer Antwort haben.

Beispiel:

time dig +short example.com @46.38.225.230

....

real 0m5.024s

user 0m0.018s

sys 0m0.005s

Die Verzögerung ist immer exakt 5s oder 10s oder ein timeout und tritt ca. jede 5. bis 10. Anfrage auf.

Wenn ich mit z.B. googles nameserver teste gibt es keine Verzögerungen.
Zuerst habe ich rate-limiting vermutet, aber selbst wenn ich ein paar Minuten warte tritt die Verzögerung wieder auf.
Ich habe debian bullyseye mit statischer netzwerk konfiguration, wie im Wiki empfohlen.

Kann das jemand reproduzieren?

Alles anzeigen

Hallo,

ich beobachte dass im Monitoring auch schon die letzten Tage. Der 46.38.252.230 läuft derzeit laut Monitoring stabiler.

Die 5 Sekunden sind der Standard Timeout von deinem DNS Client. Die 10 Sekunden halte ich für ein Gerücht, es sei denn du hast an der DNS Konfiguration gebastelt.

Gruß

Zitat von mainziman

so soll es auch sein, und da brauchst auch nur das monitoren worauf Du auch einen Einfluß hast;

sprich Deine anderen vServer ...

das mit "Als Schlussfolgerung würde ich dann aber nichts mehr im Monitoring haben" ist natürlich quatsch;

einen Webserver z.B. würdest korrekterweise ohne DNS prüfen;

zumal die Schlußfolgerung wenn es nicht funktioniert meist auch falsch ist;

Alles anzeigen

Das erinnert mich gerade an den Spruch: "Freude ist nur ein Mangel an Information" ->

Zitat von mainziman

wie Du hast nur einen einzigen vServer zum Zwecke des Monitorings?

Ich leiste mir tatsächlich den Luxus dass einer der vServer nur Monitoring und Logsammelstelle ist. Über zu wenig Arbeit beschwert sich der Host nicht.

Gleichzeitig ist das der Testhost für Containerupdates von allen Dingen die in der anderen Umgebung laufen + OS Updates. In der eigentlichen Umgebung läuft dann das Monitoring mit mindestens 2 Containern auf unterschiedlichen Hosts und HA-Failover (iPv4/v6), Zudem wird der andere Host kontrolliert. Der Traffic dazu läuft aber alles über das Cloud VLAN.

Extern hab ich dann noch tatsächlich einen Managed Monitoring Service der einfach nur prüft ob die APIs + Hosts + Webinterface des HA Monitoring erreichbar ist und wenn nicht, fängt der kleine Junge an zu schreien:

Und noch paar kleinere Hosts mit 2C 4Gb Ram wo dann standalone noch ein Docker Icinga2 in K3S läuft.

Zitat von mainziman

nein, aber wenn viele die DNS-Server von netcup monitoren - so wie eben michaeleifel - und es zufällig zu sporadischen Aussetzern kommt und dann bei netcup Tickets in Massen landen ...

von Server killen spricht noch keiner, man sollte wirklich daran denken, ob denn Resourcen auf welche man ohnehin keinen Einfluß hat,

z.B. DNS-Server die man nicht selbst betreibt, ... man ins Monitoring aufnimmt;

ich würde es nicht;

mein Router überwacht einzig ob noch Online, und wenn ja, ob der 6in4-Tunnels noch aktiv ist; mehr macht auch keinen Sinn;

Aus der Perspektive habe ich es noch nicht betrachtet. Als Schlussfolgerung würde ich dann aber nichts mehr im Monitoring haben, weil ich auf den Hypervisor der VM keinen Einfluss habe.

Deswegen frage ich auch bei meiner Prüfung einen Namen ab, der sehr geläufig ist und unter normalen Umständen eigentlich immer gecached ist. Es sei denn ich bin der einzige der mit Google sprechen will

Der Netcup DNS ist bei mir auch nur als Fallback drin, geprüft wird er aber trotzdem.

Die Stromversorgung von deinem Router betreibst du selbst? :ironie: :wink:

Zitat von mainziman

könnt nicht jemand des Monitoring in die Hand nehmen und des zentral f. alle machen?

hab irgendwie das Gefühl die vielen Monitorings veranstalten einen DDoS

sollten die DNS-Server nicht einzig durch netcup selbst gemonitored werden?

DDos ist es ja nicht wirklich wenn ich 2 mal die Minute eine Webseite aufrufe oder prüfe ob der DNS Server funktioniert Mit managed monitoring Lösungen bin ich nicht so ganz warm geworden bzgl. der Flexibilität. Läuft bei mir aber auch alles in Docker.

Ich sehe bei mir im Monitoring immer noch sporadische Aussetzer (ca. 1mal die Stunde) beim "46.38.225.230" DNS-Server. Der andere scheint bei mir stabil erreichbar zu sein.

Zitat von airru

habe das gleiche Problem. Dns wird nicht erkannt. Lösung hab ich keine gefunden.

Was kann ich mir unter "Dns wird nicht erkannt" vorstellen ? Die Information ist nicht im DHCP Lease enthalten?

Bei mir war auch kurzer Ausfall auf IPv4, allerdings alles wieder OK gewesen. Nutze per Ansible statische Konfigs und lokalen Unbound als DNS Resolver.

Hello surya

glad to hear that you found your issue.

I found that calling the shell script via keepalived isn't 100% reliable in error cases. Keepalived still manages who is "master" and who is "backup", but the IP switch itself is done through a shell script. This works as following:

- Check if file '/tmp/keepalived.status' exists

Backup Nodes:

- Check if the string "BACKUP" is inside '/tmp/keepalived.status' and Keepalived is running, print info that node is not master

Master Nodes:

- Check if the string "MASTER" is inside '/tmp/keepalived.status' and Keepalived is running

- Check if DNS works, WSDL is reachable and if Node has already the floating IP

- If so, print information that node has IP

- If not, trigger failover

#!/bin/bash
# set -eux
set -eu

# Colors
Black='\033[0;30m'        # Black
Red='\033[0;31m'          # Red
RedBlink='\033[31;5m'     # Red Blink
Green='\033[0;32m'        # Green
GreenBlink='\033[32;5m'   # Green Blink
Brown='\033[0;33m'        # Brown
BrownBlink='\033[33;5m'   # Brown Blink
Blue='\033[0;34m'         # Blue
BlueBlink='\033[34;5m'    # Blue Blink
Purple='\033[0;35m'       # Purple
PurpleBlink='\033[35;5m'  # Purple Blink
NC='\033[0m' # No Color
Bold='\033[1m'
Blink='\033[5m'



# Netcup URLs
# https://www.netcup-wiki.de/wiki/Netcup_SCP_Webservice
DOMAIN="www.servercontrolpanel.de"
WSDL="https://www.servercontrolpanel.de/WSEndUser?wsdl"
API="https://www.servercontrolpanel.de/WSEndUser"
BACKUP="BACKUP"
MASTER="MASTER"
FILE="/tmp/keepalived.status"
KEEPALIVE_PROCS=$(ps uax|grep '/usr/local/sbin/keepalived'|grep -v grep|wc -l|tr -d "\n")

# Stupid check, i know
check-dns() {
  dig +short ${DOMAIN}
}

check-wsdl() {
  curl -s -o /dev/null -w '%{http_code}' -m 10 "${WSDL}"
}

# Execute SOAP Action getVServers to check reachability
check-api() {
  curl -s -o /dev/null -w '%{http_code}' -m 10 -H 'Content-Type: text/xml; charset=utf-8' -H 'SOAPAction:' -d @/etc/netcup/getVServers.xml -X POST ${API}
}

# Execute SOAP Action getVServerIPs to check current IPs
check-ips() {
  curl -s -w '%{http_code}' -m 10 -H 'Content-Type: text/xml; charset=utf-8' -H 'SOAPAction:' -d @/etc/netcup/getVServerIPs.xml -X POST ${API} | grep -o -i XX.XX.XX.XX | wc -l
}

# Failover Process
# StatusCode 200 indicates operation has been triggered
# StatusCode 500 indicates operation isn't available, cause IP might be already switched

trigger-attach() {
  while true
  do
    STATUS=$(curl -s -o /dev/null -w '%{http_code}' -H 'Content-Type: text/xml; charset=utf-8' -H 'SOAPAction:' -d @/etc/netcup/attachIPRouting.xml -X POST ${API})
    if [ "$STATUS" -eq 200 ]; then
      echo -e "Failover: ✓ Attach is triggered!"
      break
    elif [ "$STATUS" -eq 500 ]; then
      echo -e "Attachment: ☢ Got $STATUS , seems wrong"
      echo -e "Attachment: ☹ Break back into main loop"
      break
    else
      echo -e "Attachment: ✗ Got $STATUS :( Not done yet..."
    fi
    sleep 10
  done
}

trigger-detach() {
  while true
  do
    STATUS=$(curl -s -o /dev/null -w '%{http_code}' -H 'Content-Type: text/xml; charset=utf-8' -H 'SOAPAction:' -d @/etc/netcup/detachIPRouting.xml -X POST ${API})
    if [ "$STATUS" -eq 200 ]; then
      echo -e "Detachment: ✓ Detach is triggered!"
      break
    elif [ "$STATUS" -eq 500 ]; then
      echo -e "Detachment: ☢ Got $STATUS , seems wrong"
      echo -e "Detachment: ☹ Break back into main loop"
      break
    else
      echo -e "Detachment: ✗ Got $STATUS :( Not done yet..."
    fi
    sleep 10
  done
}

### Real Stuff is down here

wait-for-dns() {
  while true
  do
    IP=$(check-dns)
    if [ -n "$IP" ]; then
      echo -e "DNS Check: ✓ SCP API resolves to $IP!"
      break
    else
      echo -e "DNS Check: ✗ Could not resolve $DOMAIN"
    fi
    sleep 10
  done
}

wait-for-wsdl() {
  while true
  do
    STATUS=$(check-wsdl)
    if [ "$STATUS" -eq 200 ]; then
      echo -e "WSDL Check: ✓ Netcup URL is reachable!"
      break
    else
      echo -e "WSDL Check: ✗ Got $STATUS :( Not done yet..."
    fi
    sleep 10
  done
}

wait-for-api() {
  while true
  do
    STATUS=$(check-api)
    if [ "$STATUS" -eq 200 ]; then
      echo -e "API Check: ✓ Netcup API is reachable!"
      break
    else
      echo -e "API Check: ✗ Got $STATUS :( Not done yet..."
    fi
    sleep 10
  done
}

main() {
  while true
  do
    if [ ! -f "$FILE" ]; then
    echo "$FILE does not exist."
    fi
    if grep -q "$MASTER" "$FILE" && [[ $KEEPALIVE_PROCS -gt 0 ]]; then
      wait-for-dns
      wait-for-wsdl
      RESULT_STRING=$(check-ips)
      if [ "$RESULT_STRING" -eq 1 ]; then
        echo -e "DeadManSwitch: ☑ Node has already XX.XX.XX.XX"
      else
        echo -e "Failover: ☐ Change FailoverIP Routing to XX.XX.XX.XX${NC}"
        wait-for-api
        trigger-attach
      fi
    elif grep -q "$BACKUP" "$FILE"; then
      echo -e "DeadManSwitch: ☑ Node is not in master state"
    else
      echo -e "Panic: errors occured!"
    fi
    sleep 60
  done
}

main

Hello,

your config is looking like it came from this blogpost: https://chr4.org/posts/2019-01…an-slash-systemd-network/

Can you tell me what you are trying to reach with your setup? Why are you trying to use a dummy interface if you have a real one available? For me it's not quite clear if you are trying to make use of an internal loadbalancer approach.

I'm using keepalived by myself with the cloud vlan and the failover ip for external access. In my case i use the cloud vlan for the communication of keepalived nodes. This is a shortened version of my config. The Nodes are having 172.16.0.11 - 13 on the eth1 Interface.

#
# Ansible managed
#

global_defs {
}

...
vrrp_script chk_kubernetes_port {
  script "/usr/bin/nc -w 2 -zv localhost 6443"
  weight 3
  timeout 3
  user nagios
}
...

vrrp_instance Netcup {
  interface eth1
  state BACKUP
  priority 101
  virtual_router_id 51
  advert_int 5

  smtp_alert

  authentication {
    auth_type PASS
    auth_pass .....
  }

  virtual_ipaddress {
    XX.XX.XX.XX/32 dev eth0
  }

  virtual_ipaddress_excluded {
    XXXX:XXXX:XXXX:XXXX::1/64 dev eth0
  }

  preempt_delay 300


  track_script {
    chk_kubernetes_port
  }


  unicast_src_ip 172.16.0.11


  unicast_peer {
    172.16.0.12
    172.16.0.13
  }

  notify "/etc/keepalived/notifications.sh" 
  notify_master "/etc/netcup/keepalived_master_ipv4.sh && /etc/netcup/keepalived_master_ipv6.sh" 
}

[netcup] Anna H.

Als kurze Überlegung. Wäre es möglich die Information von netcup-status.de in irgendeiner Art und Weise in die SCP App mit zu integrieren? Wenn dann bspw. im Bereich Netzwerk eine Störung vorliegt und ich einen Root Server habe, dann eine kleine Push Benachrichtigung oder zumindest Art Live-Ticket wäre nett.

Gruß

miotic

Frage: Ist es Absicht, dass du ein extra IPv6 Netzwerk für Docker machst oder ist das nur der angepasste Output hier fürs Forum?

Zitat von goerdi

Welche gibts denn noch ausser he.net ?

Gruss Gerd

Das hängt von ab ob du bereit bist dafür zu zahlen. Cloudflare kannst du nur in der kostenpflichtigen Version als Secondary nutzen, andernfalls sind sie der Primary. Die mir geläufigsten sind ClouDNS, DNS Made Easy, DNS Simple, AWS Route53.

Ok, und dein secondary läuft wo? Oder war das bisher dein "Hoster"?

Falls ja, dann musst du bspw deinen Hoster mit Huricane Electric ersetzen und auf deinem Primary den AXFR erlauben. Im Screenshot der Zone steht auch für welche IPs das sein muss. In der Netcup Verwaltung trägst du dann für diese Domain die Nameserver von Huricane Electric ein. Somit ist dein Primary dann immer noch "hidden".

Persönlich nutze ich einen Premium Account von Cloudns da ich DNS Failover und Monitoring brauche.

Gruß

Zitat von goerdi

Hi !

Man braucht ja 2 NS oder nicht ? wäre dann der netcup der secondary und datet sich vom master up ?

Gruss Gerd

Der Netcup "NS" Eintrag sagt dann einfach nur, dass die Zone bspw. bei H€tzner, Huricane Electric etc. liegt. Das ist nichts mit "Secondary". Er wird dann keine Anfragen für Einträge dieser Zone mehr authorativ beantworten.

Was du machen kannst:

Netcup Delegation -> dns.he.net ( Huricane Electric). In HE legst die Zone als Secondary an und erlaubst das AXFR von deinem Primary aus.

Erzähl doch mal mehr zu deinem Use-Case, dann finden wir ne Lösung.

Gruß

Mahlzeit:

Netcup als Secondary -> Nein

Delegation an "externe" NS -> Ja. Von da aus könntest dann wieder mit deinem Primary arbeiten.

Gruß

Zitat von miotic

Info: Get "https://homeip:443 -> Get "https://ipv6:443

IPV4 OK und bei IPV6 tritt der Fehler auf.

Kannst du mal in den Container reinspringen und schauen ob der überhaupt grundsätzlich IPv6 macht?

curl -I -6 https://www.google.com/

Mich würde auch interessieren ob der Host selbst IPv6 konfiguriert ist. Welches OS nutzt du denn? Hab Matrix selber am laufen, allerdings mit dem ananace/matrix-synapseDocker Image.

Zitat von Olivetti

evtl. den rss feed parsen.

Code

curl -sSN "https://www.netcup-status.de/feed/" | xq -r '.[].channel.item[] | {titl: .title, desc: .description}'

Das liest sich schon mal als erster Anfang gut. Welcher "xq" ist es denn? Der RSS Feed enthält nur soweit ich sehe nicht den aktuellen Status der jeweiligen Störung. Man könnte allerdings die "<guid isPermaLink="false" </guid>" nutzen um dann weiter zu parsen...

Ich weiß nicht ob es schon mal gefragt wurde:

Gibt es einen Weg programmatisch an die Information von https://www.netcup-status.de/ zu kommen? Shell-Skripting etc.? Versuche gerade diese Informationen irgendwie in mein Monitoring zu kriegen, sodass ich bei nem Ausfall Korrelationen betreiben kann. Über das SCP oder WCP gibt es da ja soweit ich sehen kann nichts.

Gruß

Moin,

1.) Nicht dass mir bekannt wäre oder in AGb stehen würde, ein Cloud VLAN könnte sich aber lohnen dass der Traffic nicht alles über "öffentliche" Netze lläuft.

2.) siehe 1

3.) Hab das Cluster seit ca 3 Jahren bei Netcup auf Debian Basis mit Kubespray aufgesetzt und Multi-Master HA. Zum provisionieren nutze ich Preseed + Ansible.

Tipps:

- HA aufsetzen falls möglich

- Floating IP: https://www.netcup.de/bestellen/produkt.php?produkt=1073 die dann per keepalived verwaltet wird, sodass bei einem Node-Ausfall weiterhin über gleiche IP an deine Dienste kommt

- Backups einrichten

- Ansible / Automatisierung nutzen falls möglich

- DNS Dienst der Healthchecks machen kann als Fallback wenn das Failover der IP aus irgendeinem Grund hakt.