[SOLVED] Webseiten teilweise nicht erreichbar

Started by meschmesch, March 02, 2022, 04:32:19 PM

Previous topic - Next topic
March 02, 2022, 04:32:19 PM Last Edit: March 08, 2022, 09:43:40 AM by meschmesch
Hallo,
ich habe seit kurzem das Problem, dass ich im Netzwerk diverse Webseiten nicht mehr erreichen kann, darunter https://www.routerperformance.net/opnsense-repo/ (die definitiv online ist). Ping auf www.routerperformance.net funktioniert, nslookup auch. Ich habe weder ein Update gemacht, noch sonst irgendwas verändert. Da adguard über das o.g. repositoy installiert ist, funktionieren Updates auch nicht (update hängt bei dem Versuch, von mimugmail Daten abzurufen). Ich bin auf 21.7.8

Das Problem habe ich für viele unterschiedliche Domains, weiß aber nicht warum. Wie kann ich die Fehlerquelle finden?

Danke!!

UPDATE: Wenn ich CARP temporär deaktiviere, sind manche (nicht alle) Webseiten zugänglich. Ich habe keine Ahnung was da läuft.

Hat denn keiner eine Idee? Ich bin mit meinem Latein am Ende. Updates funktionieren nicht, weder auf der Backup-Firewall, noch auf der Haupt-Firewall. Ich sehe im Firewall-Log, dass Verbindungen rausgehen, aber wie gesagt, bei verschiedenen Webseiten kommt nichts rein. Selbst wenn ich Zenarmor auf Bypass stelle, Adguard deaktiviere. Ich habe schlichtweg keine Ahnung, wie ich hier eine Diagnose machen soll, wo ich ansetzen soll.  :-X

Dann mal doch bitte mal deine Firewall- und Netzwerkstruktur vollständig auf, sonst wird Hilfe schwierig.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: meschmesch on March 02, 2022, 04:32:19 PM
Hallo,
ich habe seit kurzem das Problem, dass ich im Netzwerk diverse Webseiten nicht mehr erreichen kann, darunter https://www.routerperformance.net/opnsense-repo/
Hast du IPv6 aktiviert ?

Gerade bei routerperformance.net hatte ich ähnliche Probleme, das der Zugriff auf das Repo extrem langsam war und auch die Paketlisten nicht vollständigen waren.

Empfehlung war, unter System -> Settings -> General
"Prefer to use IPv4 even if IPv6 is available". zu aktivieren.
Seitdem geht es auch wieder problemlos - Ursache: der Zielserver kann kein IPv6

March 04, 2022, 07:53:41 AM #4 Last Edit: March 04, 2022, 02:57:10 PM by meschmesch
Hallo,
"Prefer to use IPv4 even if IPv6 is available" hat geholfen, als ich unter 21.7.8 war. Update auf 22.1.2_1 war möglich. Jetzt ist es allerdings so, dass "Prefer to use IPv4 even if IPv6 is available" scheinbar keine Wirkung mehr hat?! Viele Webseiten sind wieder nicht erreichbar, darunter auch routerperformance.net.

pkg -4 update hilft auch nicht.

Hier Mein Aufbau des Netzwerks:

WAN Fritzbox:
-   IPv6-Präfix: 2axx:xxxx:xxxx:fe20::/60
-   IPv4 Route 192.168.2.0, Gateway 192.168.1.3
-   IPv6 Route 2axx:xxxx:xxxx:fe28::, Gateway 2axx:xxxx:xxxx:fe20::100
-   IPv4 der Fritzbox 192.168.1.1

WAN Opnsense

-   IPv4 DHCP
-   IPv6 DHCP
-   CARP Adressen 192.168.1.3/24 bzw. 2axx:xxxx:xxxx:fe20::100/6

LAN Opnsense

-   Statische IPv4 192.168.2.2
-   Statische IPv6 2axx:xxxx:xxxx:fe28::2
-   Carp 192.168.2.1/24 bzw. fe80::2:2/64 bzw. fd00::2:1/64
-   DHCPv4 mit DNS Server 192.168.2.1, Gateway 192.168.2.1, Failover peer IP 192.168.2.8
-   Router Advertisements Stateless, High, Source Address ist IPv6 Lan Carp (fe80::2:2)

Gateways Opnsense

-   WAN_Virtuell    WAN    IPv4    250 (upstream)    192.168.1.3
-   WAN_DHCP6 (active)    WAN    IPv6    250    fe80::3ea6:2f... (fe80 der Fritzbox)
-   WAN_DHCP (active)    WAN    IPv4    254    192.168.1.1

NAT Opnsense
-   WAN    LAN net    *    *    *    192.168.1.3

Port Forward Opnsene
-   LAN    TCP/UDP    *    *    192.168.2.1    53 (DNS)    192.168.2.2    53 (DNS)

Adguard macht DNS Auflösung. Dazu in Opnsense System-Settings-General
-   DNS Server 192.168.2.2 und fd00::2:1
-   Prefer to use IPv4 even if IPv6 is available
-   Do not use the local DNS service as a nameserver for this system
-   Allow default gateway switching

Ping auf die nicht erreichbaren Webseiten funktioniert mit IPv4 und IPv6.

Aufbau:
Fritzbox – Switch  (Verzweigung nach OpnSense1 (wie oben beschrieben) und OpnSense2 (Backup) – Switch - LAN 


UPDATE: Nachdem ich an den Gatways, Outbound NAT und anderen Dingen ein paar Stunden rumgespielt habe, ohne auch nur einen Parameter im Endeffekt zu verändern, tut jetzt gerade alles, selbst wenn ich "Prefer to use IPv4 even if IPv6 is available" wieder deaktiviert habe. Das ist alles nicht nachvollziehbar und sehr seltsam.

Kann es sein, dass sich das Teil irgendwo "verschluckt", wobei selbst Reboots das nicht beheben können?

Ich beobachte das noch und berichte weiter.

Ist das IPv6 PD das du auf deiner FritzBox erhälst statisch oder verändert es sich bei Verbindungsverlust?

Läuft IPv6 zuverlässig weiter nachdem du das WAN-Kabel kurz aus- und wieder einsteckst und danach die Verbindung wieder aufgebaut wurde?

Ist statisch. Und ja, alles läuft zuverlässig weiter.

Auf der Backup Firewall habe ich mit Hängen und Würgen das Upgrade auf 22.1.2.1 hinbekommen. Aber hier dasselbe Problem dass zb http://www.routerperformance.net/ nicht erreichbar ist. Auf der Hauptfirewall zum gleichen Zeitpunkt geht es jedoch.

March 05, 2022, 01:48:27 PM #8 Last Edit: March 05, 2022, 02:11:25 PM by ar
Nur dem Verständnis wegen: Das Problem ist die Daten über HTTP/HTTPS nicht korrekt transportiert werden, ICMP und andere Protokolle funktionieren einwandfrei wenn ich das richtig lese korrekt?

Du hast keinen Webproxy aktiviert und verteilst auch keine DHCP-Optionen die einen Webproxy vorschlagen, der dann nicht erreichbar ist?

Adguard DNS ist bei dir selbst gehostet oder verwendest du deren Public DNS-Server und wenn ja, welche Variante / welche Filterlisten gehen da rüber?

Bei dir geht das Repo selbst langsam, die Webseite absolut gar nicht?

Weder opn-repo.routerperformance.net noch www.routerperformance.net sind über IPv6 erreichbar, von daher sollte es tatsächlich kein Problem damit sein, es sei denn dein Anbieter muss IPv4 tunneln, was durchaus eine Fehlerquelle sein könnte.

Rein vom Nameserver-Eintrag her sehe ich auch kein Problem


www.routerperformance.net. 3600 IN      CNAME   web03-01.max-it.de.
web03-01.max-it.de.     86400   IN      A       81.24.64.215


sonst dürfte es schon mit der Auflösung Probleme geben.

Was bedeutet "mit Hängen und Würgen" bei einem Upgrade, was genau ist denn das Problem? Verwendest du Hardware- oder Software Offloading für die Netzwerkkarten?

Hast du ausgeschlossen das es nicht einfach nur am Server von routerperformance.net liegen könnte? ICMP ist einfacher beantwortet als ein überlasteter NGINX, der auf einem 5€ Host läuft mit gedrosselter CPU/Bandbreite.

Was genau passiert wenn du über cURL eine Verbindung aufbaust von einem Client der Probleme macht?


curl -i --trace - https://opn-repo.routerperformance.net

== Info:   Trying 46.16.78.247:443...
== Info: TCP_NODELAY set
== Info: Connected to opn-repo.routerperformance.net (46.16.78.247) port 443 (#0)
== Info: ALPN, offering h2
== Info: ALPN, offering http/1.1


Hast du geprüft das es nicht ein Problem mit einer deiner beiden WAN-Leitungen sein kann?

Ansonsten kann ich da nicht mehr raus lesen, da das echt viel gleichzeitig ist was da schief gehen könnte. Du schreibst zwar das du über eine Link Local-Adresse auf die FritzBox routest am Gateway, aber bei der Fritzbox erwähnst du keine. Dein LAN scheint ULA, PD und DHCPv6 gleichzeitig zu nutzen, eventuell hängt das mit dem MutliWAN zusammen, aber warum dann ULA überhaupt bei einer statischen IP?

Ich bin absolut kein IPv6-Profi, von daher weiss ich nicht ob irgendwas davon hilft, aber generell würde ich mit Wireguard mal schauen was zur Hölle mit den Paketen passiert, wer und über welche IP / welches Interfaces die gehen "wollen" bei den Protokollen die rumspinnen und ob dir da eventuell ein ungewolltest NAT in die Quere kommt.

ICMP geht, DNS geht, HTTP(S) geht manchmal ... klingt nach MTU/MSS.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: ar on March 05, 2022, 01:48:27 PM
....
Bei dir geht das Repo selbst langsam, die Webseite absolut gar nicht?

Weder opn-repo.routerperformance.net noch www.routerperformance.net sind über IPv6 erreichbar, von daher sollte es tatsächlich kein Problem damit sein, es sei denn dein Anbieter muss IPv4 tunneln, was durchaus eine Fehlerquelle sein könnte.
....
sonst dürfte es schon mit der Auflösung Probleme geben.

Was bedeutet "mit Hängen und Würgen" bei einem Upgrade, was genau ist denn das Problem? Verwendest du Hardware- oder Software Offloading für die Netzwerkkarten?
...
Das ist aber genau das Verhalten, was ich auch hatte und in #3 schone geschrieben habe, und mit "Prefer to use IPv4 even if IPv6 is available" aktivieren, behoben konnte.

Das Repo von routerperformance was grottenlangsam, alleine schon das zufügen des Repos zum OS dauerte ewig und das Update des normalen Repos von OPNSense war komplett unvollständig, es fehlte etliche Pakete in der Liste.
Hab ich routerperformance als Repos wieder gelöscht, war alles normal und funtkionierte - Ursache, der Hoster von routerperformance kann keine IPv6 ( willkomm im 21. Jahrhundert sag ich da nur )
Warum sich das so drastisch auf die Standart-Repos auswirkt, weiss ich nicht.

Mein Anschluss hat Dual-Stack und da liegt das Problem nicht.

Derzeit beobachte ich ein ähnliches Verhalten bei einzelnen meiner Linux-Server, die Probleme mit github.com haben, aber da hab ich noch noch nicht weiter nach geschaut.

Hallo,
in der Zwischenzeit läuft wieder alles, so wie es soll. Alle Webseiten sind (ohne Tick "Prefer to use IPv4 even if IPv6 is available") problemlos erreichbar. Was habe ich geändert? Nichts. Absolut nichts.

Insofern kann ich im Nachhinein auch nicht mehr testen/nachvollziehen, an was es lag. Dennoch danke für den Versuch einer Aufklärung. Wenn ich im Nachhinein doch noch irgendwas tun kann, um das ganze zu erhellen, sehr gerne. Bitte lasst es mich wissen.  :-[


Strange - würde mich doch mal interessieren, was das war.

Wie geschrieben, ich habe gerade das selbe Problem mit github.com, per Webbrowser kein Problem, nslookup udn curl kein Problem, Abfrage der Repos dauert ewig. und bricht meist mit Timeout ab.