Posts by michaeleifel

    Also ich als Manager eines großen Autokonzerns Webhosters würde da meinen Mitarbeitern nahelegen, eine Software einzubauen, die einen Speedtest erkennt und bei einem solchen Test - und nur dann - die maximale Bandbreite zur Verfügung stellt. :D;(

    Leicht Offtopic: https://github.com/auchenberg/volkswagen

    Garantierte Bandbreite wäre mir manchmal deutlich lieber als "unlimited". Wäre mal interessant zu wissen ob Netcup intern die Cloud VLAN Bandbreite garantiert. Die wäre mir noch wichtiger dass ich dort den Speed habe als die Verbindung nach außen.

    Möchtest du uns vielleicht sagen was die Einschränkung genau ist? Der Link auf die Doku ist nett um es nachzuvollziehen, aber noch sehe ich nicht genau was dich dazu zwingt zu wechseln.


    Ich werfe mal pauschal den HAProxy in den Raum, gibt eigentlich kaum was, was man nicht damit abbilden kann. Auch verschiedene Resolver für Frontends / Backends.

    Okay, das verstehe ich jetzt.


    Der keepalived läuft aber in dem Fall nicht als pod, oder? Der kann überall laufen, wo der Ingress Endpunkte hat. Die prüft der keepalived. Falls der master nicht mehr healthy ist, würde also einfach der nächste übernehmen, die IP umschalten und dann sind alle Ports direkt wieder erreichbar, nur eben auf dem anderen Node.

    Soweit korrekt. Keepalived läuft auf der Node selber tatsächlich, konfiguriert / installiert per Ansible. Ich habe 3 Master. Die Worker Nodes sprechen immer lokal gegen einen HAProxy, der als Backends alle 3 API Endpunkte der Master hat.


    Wenn jetzt Master 1 ausfällt, kratzt den Worker das nicht, weil er über den HAProxy immer noch mit den beiden anderen Mastern sprechen kann (loadbalanced API). Soweit zum Cluster internen Ablauf.


    Externer Ablauf:

    - Sowohl die IPv4 als auch die IPv6 werden über die Shellskripte umgeschaltet. Die IP Konfiguration ist in Keepalived hinterlegt, sodass nur der aktive Master auch wirklich die Floating IP auf dem Interface konfiguriert hat. In dem Moment wo ich keepalived beende, verschwindet auch die FloatingIP vom Interface, falls die Node Master war. Die Shellskripte prüfen jede Minute den Status von Keepalived und falls die Node Master ist, wird zusätzlich geprüft ob der Node die Floating IP zugewiesen ist. Falls nicht, wird diese zugewiesen. Dies trifft sowohl auf die Kubernetes API IP zu, als auch die Ingress IP über welche ich dann meine Seiten erreiche.


    Bis auf die bereits erwähnten ca. 20 Sekunden fällt es mir nicht aktiv auf, wenn die IP rumgeschoben wird. Mein externes Monitoring prüft alle Seiten im 30 Sekundentakt und selbst dort ist es selten zu sehen. Mittlerweile hab ich auch in Icinga2 ein dynamisches Monitoring Skript für keepalived:

    - prüfe ob Node master ist (keepalived status)

    - Falls master. sind die FlaotingIPs auf dem Interface up

    - Falls slave, Node sollte keine FloatingIP haben


    Gruß

    Zum Verständnis: wo läuft der HA Proxy? Ist das auf dem Kubernetes Node wo etcd bzw. die Controlplane läuft? Oder läuft der innerhalb vom Kubernetes als Pod? Was läuft alles auf dem Master?

    Der HAProxy läuft als Pod in Kubernetes, exposed aber per Konfiguration verschiedene Ports. Auf den Nodes / Workern läuft aber auch ein HAProxy der die Kubernetes API von den Master loadbalanced. Deswegen macht das Umschalten der Floating IP auch gar nichts im Cluster selbst sondern dadurch ist "nur" die Verbindung von draußen an die FloatingIP unterbrochen. Das der Ingress aber auch auf allen Nodes auf alle Requests reagiert und sie weiterleitet, kann jede beliebige Node auch bspw per "/etc/hosts" angesprochen werden.

    Kubernetes API Check-Skript: (Vorher entsprechenden Service Account / RBAC anlegen)


    Shell-Script
    1. #!/bin/bash
    2. TOKEN=XXXX
    3. [ -z $(curl -m 2 -s -f -H "Authorization: Bearer $TOKEN" -k "https://localhost:6443/api/v1/nodes/$HOSTNAME" | jq -r '.spec.unschedulable | select(.==true)') ] && exit 0 || exit 1

    Das rumschieben über die SOAP API absolvieren dann zwei Shellskript die als Daemon auf dem System laufen und von keepalived benachrichtigt werden.


    Die Keepalived Konfiguration beinhaltet sowohl eine IPv4 als auch eine IPv6 Floating IP, welche über die gleiche Keepalived Instanz verwaltet werden, daher die etwas komische "virtual_ipaddress_excluded" Notation.

    Habe 3 Master im Einsatz die über ein CloudVLAN miteinander kommunizieren. Nach außen hin switche ich die FailoverIP, das ist <20 Sekunden eigentlich erledigt. Das passiert automatisch über Keepalived was Checks ausführt. Bspw wenn ich eine Node tainte, dann wird die IP verschoben.


    Schneller geht`s beim Loadbalancer auch nicht unbedingt, es sei denn man hat sekündliche Healthchecks. VPS500 sollte reichen, wichtig ist auf jeden Fall ne 2C Maschine.

    Und auf dieses Angebot würfde ich auch gerne zurückkommen ;-)


    Ich werde aber noch berichten, ob Deine Config läuft.

    Gibt es denn einen Grund warum du UFW und Iptables mixt, wenn du bereits iptables im Einsatz hast? Im Zweifel suchst du immer an 2 Stellen.


    Ich würde halt nicht nur über die Firewall DNS Anfragen blocken sondern den DNS Server entsprechend konfigurieren, dass er nur für bestimmte IPs / Netze antwortet. Für die fortgeschrittene Variante Ipset in Verbindung mit DynDNS Reverse Lookup für Verwendung des Pihole / Unbound / DNS als Upstream in der Fritzbox.. ;-)

    Ist die IPv6 Adresse aus deinem Prefix Bereich? Weil ansonsten bekommst du Probleme mit dem Routing. Frage: Warum machst du NAT auf IPv6, wenn du mit einer öffentlichen IPv6 arbeitest? Da kannst du auch vollwertig routen. Oder alternativ eine ULA Adresse nehmen.


    Nachtrag: Wenn du hier mit öffentlichen IPs ohne NAT arbeitest, musst du natürlich auch NDPP ans Laufen bringen.


    Ich glaube die hat er aus meiner Konfig heraus kopiert, siehe 1. Post. Mein Zweck dahinter ist, dass ich mich nicht mit blöden Routern rumschlagen muss die sich entscheiden ULA anders zu routen, schon die besten Stories erlebt. Da mir ein /64 Ipv6 netz zugeordnet ist, nutze ich einfach das Subnetz und trickse die Router aus und bisher hatte ich keinen Fall wo das nicht geklappt hat.


    Gruß


    Code
    1. root@node ~ # netstat -lnp | grep 51820
    2. udp 0 0 0.0.0.0:51820 0.0.0.0:* -
    3. udp6 0 0 :::51820 :::* -

    Die Konfiguration von "ndppd" hatte ich mal gemacht weil Wireguard im Docker Container lief. Mit der oben genannten Konfig hab ich sowohl IPv4 als auch IPv6 alles über den Server laufen.


    Das macht nie der Anbieter, das ist immer eine Sache des Endgeräts.

    Da melde ich zumindest Zweifel an. Das Problem hab ich nämlich bei 2 verschiedenen DSL Anbietern. Gleicher DNS Name, bei Anbieter A bevorzugt über IPv6, bei Anbieter B IPv4.


    DNS Server, FritzBox Einstellungen + OS Version + Endgerät das selbe.

    Sprich du hast keine Domäne oder ähnliches? Dann bliebe der Umweg über einen DynDNS Service der sowohl IPv4 als auch IPv6 anbietet als Mittellösung, wenn du keine ganze Domäne "mieten" möchtest. Wenn der Server bei Netcup ist, dann sollte er auch ein /64 IPv6 Netz haben.


    Ich hätte ne Domäne zu Testzwecken rumfliegen.

    Noch mal die Frage: Warum funktioniert IPv4 über Mobilfunk nicht? Ich kann mir beim besten Willen nicht vorstellen, dass es einen Mobilfunkprovider gibt, der keine IPv4 Adressen verteilt. Wer ist der Anbieter?


    Möglicherweise können wir uns viel Konfigurationsgewusel sparen, wenn sich am Ende herausstellt, dass wir IPv6 gar nicht brauchen.

    Dann hast trotzdem Problem wenn dein Anbieter IPv6 "bevorzugt", in der Falle saß ich nämlich an einem normalen Telekom DSL Anschluss.


    Gruß

    Um Gottes Willen, wie könnte das böse gemeint sein, Du versuchst mir zu helfen!


    Danke für Deine Geduld mit mir :-)

    Ok, dann fangen wir mal mit dem ganz einfachen an:

    Endpoint = 185.207.105.144:51820


    Kannst du auf der Node mal prüfen, ob dann über IPv6 überhaupt was lauscht? Andernfalls wäre das der erste Punkt warum IPv6 nicht tut.

    Bei mir sieht das wie folgt aus:


    Code
    1. root@node ~ # netstat -lnp | grep 51820
    2. udp        0      0 0.0.0.0:51820           0.0.0.0:*                           -                    
    3. udp6       0      0 :::51820                :::*                                -     


    Gruß


    Hallo,

    Jetzt haben wir ja geklärt dass der sämtliche Traffic über den vServer laufen soll und dass wir in unbound / pihole noch auf Netzwerke beschränken aus denen Abfragem erfolgen.


    Mir würde es helfen wenn wir der Reihe nach vorgehen und nicht UFW und Iptables direkt miteinander vermengen. An UFW würde ich erst rumbasteln wenn der Rest läuft. Zumal du den Port 53 auch nicht Richtung Internet aufmachen willst.


    Könntest du dann jetzt die derzeit aktive Konfig nach dem Reset hier posten dass wir dann den richtigen Stand analysieren?


    Das ist jetzt nicht böse gemeint, aber durch die diversen Verzweigungen bin ich mir gerade nicht mehr sicher was der aktuelle Stand ist. Ich kann nachher mal wieder ne Node mit Ansible provisionen wo das angestrebte Setup funktioniert. Danach kann ich dann auch mal paar Konfigs hier posten


    Gruß

    Also entweder täusche ich mich, aber das sieht für mich komisch aus auf den ersten Blick


    Endpoint = 185.207.105.144:51820 in der Konfig:

    Code
    1. # nano /home/vpn/configs/papa.conf
    2. [Interface]
    3. PrivateKey = 4J***********************o=
    4. Address = 10.6.0.2/24
    5. DNS = 10.6.0.1
    6. [Peer]
    7. PublicKey = FhdsKWz/zzUlCoUT1Up1bmlZtpFTAE/s36UslT9RnHc=
    8. PresharedKey = xF**************************s=
    9. Endpoint = 185.207.105.144:51820
    10. AllowedIPs = 0.0.0.0/0, ::0/0

    Das wäre natürlich eine Erklärung warum IPv6 gar nicht geht.


    Bei mir habe ich dort einen DNS Namen eingetragen, der sowohl als IPv4 (A) als auch IPv6 (AAAA) auflöst. Den Rest deiner Konfig schaue ich mir später an, nur als erstes Feedback

    Mahlzeit,

    ich glaube ich war neulich in einem ähnlichen Problem gefangen bei einem anderen Provider.


    Fangen wir mal mit den Basics an:

    1.) Netzwerk Konfiguration der Maschine bitte mal posten (kannst X nutzen, geht mir hauptsächlich drum wie IPv6 konfiguriert ist)

    2.) Funktioniert ping6 auf externe Ressourcen, sprich hat die Maschine IPv6 Konnektivität?

    3.) In der Wireguard Konfig hab ich zusätzlich neben IPv4 auch IPv6 Adressen eingetragen:

    Code
    1. [Interface]
    2. Address = {{ vpn_network }}.1/24, {{ vpn_network6 }}:dada::1/80

    4.) Um Ipv6 Konnektivität über Wireguard nach draußen zu haben, nutze ich noch ndppd

    Code
    1. proxy eth0 {
    2. timeout 500
    3. ttl 16000
    4. rule {{ vpn_network6 }}:dada::/64 {
    5. static
    6. }
    7. }

    Der letzte Punkt war bei mir dann der Durchbruch um auch getunneltes IPv6 zu haben.


    EDIT:
    Gerade nochmal das Ansible Playbook ausgepackt und Node provisioniert. scheint weiterhin zu funktionieren:

    pasted-from-clipboard.png

    Danke, daran habe ich ebenfalls noch nicht gedacht. Dachte das wäre ein gängiges Verfahren. Wo läuft denn bei dir der RP? Ich habe nur ein Webhosting Paket bei Netcup. Mein RP läuft lokal hinter dem Router. Dort ist aber nur ein SSL Port offen. Der Redirekt müsste also vorher erfolgen.

    Bei mir läuft der RP auf nem Raspberry hinter der Fritz!Box. Port 80 und 443 werden gegen den PI geforwarded. Dadurch passiert auch der SSL Redirect.

    Ah ja, Mist. Hatte gehofft, ich könnte den Redirect vorher noch irgendwie vornehmen. Ich glaube bei Myfritz geht das nicht. Dann muss ich mir wohl doch einen separaten DynDNS besorgen. Vielen Dank für den Hinweis, Michael.

    Ich wüsste allerdings derzeit nicht welcher DynDNS anbietet den HTTP Redirect auf DNS Ebene zu machen. Persönlich löse ich das ganze mit nem ReverseProxy der den Redirect macht. Oder halt Bookmark hinterlegen der direkt auf HTTPS geht.

    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ß

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

    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.