Alarm! 
(Referenz:
Zitat1 Time(s): eth0: renamed from vetha9xxcc991
1 Time(s): veth7eeebxx: renamed from eth0
Ich vermute mal du hast `net.ifnames=0` oder ähnliches gesetzt in grub. https://www.freedesktop.org/wi…bleNetworkInterfaceNames/
ZitatAlles anzeigen
1 Time(s): device veth3643dxx0 left promiscuous mode
1 Time(s): device veth441a2exx6 entered promiscuous mode
3 Time(s): docker0: port 2(veth36xxx43d90) entered disabled state
3 Time(s): docker0: port 2(veth441axx2e6) entered blocking state
2 Time(s): docker0: port 2(veth441a2xxe6) entered disabled state
2 Time(s): docker0: port 2(veth441axx2e6) entered forwarding state
Das ist völlig normal wenn der Docker Daemon / Container gestartet / gestoppt werden.
1 Time(s): TCP: request_sock_TCP: Possible SYN flooding on port xy. Sending cookies. Check SNMP countersBitte mal die Ausgabe von
sysctl net.ipv4.tcp_syncookiesposten.
Ich habe beides im Einsatz. Prinzipiell gefällt mir Debian an der Stelle etwas besser da es konservativer ist und viele der Dinge auf dem System selber konfiguriere per Automatisierung wie bspw DNS Cache etc.
Unter Ubuntu 20.04 stören mich etwas diese ganzen SystemD Dienste + Snap / Netplan Sachen etwas.
Was ich nett finde ist, dass ich aus den Backports die für mich nötige Software auch in aktuellen Versionen bekomme, was bei Ubuntu nicht der Fall ist. Beispielsweise für Unbound.
Mahlzeit,
gibt verschiedene Wege. Das hängt wohl mit der LetsEncrpt Umstellung zusammen: https://www.heise.de/news/Let-…ber-moeglich-6201155.html
Nr 1:
sudo apt-get install --reinstall ca-certificatesNr 2:
sudo mkdir /usr/local/share/ca-certificates/cacert.org
sudo wget -P /usr/local/share/ca-certificates/cacert.org http://www.cacert.org/certs/root.crt http://www.cacert.org/certs/class3.crt
sudo update-ca-certificatesAlso ich als Manager eines
großen AutokonzernsWebhosters 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.
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.
#
# Ansible managed
#
global_defs {
notification_email {
ich@du.de
}
notification_email_from k8s-master-1
smtp_server 127.0.0.1
smtp_connect_timeout 30
script_user root
enable_script_security
}
vrrp_script chk_dns_resolver {
script "/usr/bin/nc -w 2 -zv 127.0.0.53 53"
weight 5
timeout 3
user nagios
}
vrrp_script chk_haproxy {
script "/usr/bin/killall -0 haproxy"
weight 5
interval 2
timeout 3
}
vrrp_script chk_haproxy_port {
script "/usr/bin/curl -m 2 --silent --show-error --fail http://127.0.0.1:10254/healthz"
weight 5
interval 2
timeout 3
}
vrrp_script chk_http_port {
script "/usr/bin/curl -m 2 --silent --show-error --fail http://localhost/healthz"
weight 5
interval 3
timeout 3
}
vrrp_script chk_kubelet_port {
script "/usr/bin/curl -m 2 --silent --show-error --fail http://127.0.0.1:10248/healthz"
weight 5
interval 3
timeout 3
}
vrrp_script chk_kubernetes_health {
script "/etc/keepalived/keepalived_check_script.sh"
weight 30
timeout 3
}
vrrp_script chk_kubernetes_port {
script "/usr/bin/nc -w 2 -zv localhost 6443"
weight 3
timeout 3
user nagios
}
vrrp_script chk_sshd {
script "/usr/bin/killall -0 sshd"
weight 4
interval 2
timeout 3
}
vrrp_instance Netcup {
interface eth1
state BACKUP
priority 101
virtual_router_id 51
advert_int 5
smtp_alert
authentication {
auth_type AH
auth_pass XXXXXXXX
}
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_dns_resolver
chk_etcd_client_port
chk_etcd_peer_port
chk_haproxy
chk_haproxy_port
chk_http_port
chk_kubelet_port
chk_kubernetes_health
chk_kubernetes_port
chk_sshd
}
vmac_xmit_base
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"
}Kubernetes API Check-Skript: (Vorher entsprechenden Service Account / RBAC anlegen)
#!/bin/bash
TOKEN=XXXX
[ -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 1Das 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ß
root@node ~ # cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.100.100.1/24, 2001:8d8:1801:81c5:dada::1/80
SaveConfig = false
ListenPort = 51820
PrivateKey = XXXXX
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
PublicKey = aTwJHL9Rnxn1pQ57FfwiHxy4UNUAYPZ+O/j6iG9LoTQ=
AllowedIPs = 10.100.100.2/32, 2001:8d8:1801:XXXX:dada::2/128root@node ~ # netstat -lnp | grep 51820
udp 0 0 0.0.0.0:51820 0.0.0.0:* -
udp6 0 0 :::51820 :::* -❯ cat wg0-client.conf
[Interface]
Address = 10.100.100.2/32, 2001:8d8:1801:XXXX:dada::2/128
DNS = 10.100.100.1
PrivateKey = XXXXX
[Peer]
PublicKey = 2cjz/Jz024p1mS73cBrjFVKmV12X+ZsxII0z92KfWzE=
AllowedIPs = 0.0.0.0/0,::/0
Endpoint = wireguard.wurstgraf.de:51820
PersistentKeepalive = 30Die 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.
Alles anzeigenIch habe keinen Hostnamen nur die IP-Adresse meines Servers. Das ist eben die 185.207.105.144.
Und es funktioniert ja auch, aber eben nur wenn der Client eine IPv4 und keine IPv6 Adresse hat
Wenn ich das heimische WLAN verlasse und in Mobilfunk gehe und dann meine IP-Adresse abfrage, bekomme ich eine IPv6-Adresse angezeigt.
Mein Provider ist Pennymobil (= Congstar = Telekom).
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:
root@node ~ # netstat -lnp | grep 51820
udp 0 0 0.0.0.0:51820 0.0.0.0:* -
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:
# nano /home/vpn/configs/papa.conf
[Interface]
PrivateKey = 4J***********************o=
Address = 10.6.0.2/24
DNS = 10.6.0.1
[Peer]
PublicKey = FhdsKWz/zzUlCoUT1Up1bmlZtpFTAE/s36UslT9RnHc=
PresharedKey = xF**************************s=
Endpoint = 185.207.105.144:51820
AllowedIPs = 0.0.0.0/0, ::0/0Das 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:
[Interface]
Address = {{ vpn_network }}.1/24, {{ vpn_network6 }}:dada::1/804.) Um Ipv6 Konnektivität über Wireguard nach draußen zu haben, nutze ich noch ndppd
proxy eth0 {
timeout 500
ttl 16000
rule {{ vpn_network6 }}:dada::/64 {
static
}
}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:
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.
