Posts by H6G

    deswegen bitte ich um eine Erklärung, wie genau das funktioniert.

    Links Mitte Rechts
    @ TXT google-site-verification=gaaaaaanzLangerText

    Dann auf speichern klicken.

    Die Meldung, dass die Domain unbrauchbar wird, kannst du dabei ignorieren.

    ahh check jetzt hab ich es glaub ich danke

    Supi. Kleiner Hinweis: die Routingtabelle wird nach einem Neustart wieder zurückgesetzt.

    Du könntest dir damit ein Script anlegen, was beim Start dir die notwendigen Daten in die Tabelle schreibt.



    natürlich statt der ext.IP die wo ich hin will

    In deiner Zeichnung stehen leider nicht die internen Tunneladressen und die RFC1918 Adressen auf der rechten Seite sind auch nicht vollständig beschrieben. Das macht die Kommunikation etwas schwieriger.

    doch jetzt bekomme ich bei tracert ein time out

    Auf dem Gegenstück zum IPSec Tunnel, brauchst du natürlich die entsprechenden Rückrouten für das 10.0.0.0er Netz.


    Edit: außerdem ist via 185....ext.linux kompletter Murx. Du willst doch durch den VPN und durch den Tunnel routen. Da hat die Public IP von keiner Maschine etwas zu suchen.

    Erste Stoßrichtung ist definitiv Signal (wohl via Verknüpfung mit signal-cli), danach ggf. E-Mail und IRC. Die Sammlung existierender mqttwarn-Plugins gefällt mir als Grundlage eigentlich recht gut, die Nutzerbasis scheint nicht allzu klein zu sein.

    Reicht es dir, wenn ein entsprechender Daemon ein Executable aufruft mit dir bekannten Aufrufparametern?

    Da kann man dann ein Go-Executable ranhängen, ein Bashscript, oder ein Python Script :P

    Der Traceroute zeigt, dass die Pakete ins Internet gehen, und nicht durch den Tunnel.

    Du musst auf dem Linux entsprechende Routen anlegen:


    ip route add Netz/CIDR via IP


    Auf dem Gegenstück zum IPSec Tunnel, brauchst du natürlich die entsprechenden Rückrouten für das 10.0.0.0er Netz.

    Wenn du komplexere Tunnel hast, solltest du über ein Routing Protokoll nachdenken (OSPF, RIP, IS-IS und was es da nicht noch so alles gibt)

    Nur kurz der Vollständigkeit halber: In dem Blogpost geht der Kollege hin und weißt seinem Netzwerkinterface die Adresse als /128 zu, nicht als /64. Damit liegt sie natürlich außerhalb des /80 Netzes für die Bridge. Das wäre IP-mäßig sauber. Aber wie gesagt: Offenbar ein rein kosmetisches Problem.

    Die Netzmasken sind nur für die Routing Tabelle wichtig.

    Je spezifischer eine Netzmaske ist - sprich desto kleiner das Netz ist, was sie abdeckt, desto höher die Priorität in der Routingtabelle.

    Probleme gibt es nur, wenn die Netzmasken identisch sind. Überlappende Masken sind kein Problem.


    Das sind zumindestens die Standardregeln die im Linux Kernel, im BSD Kernel, unter Cisco iOS funktionieren.

    Andere Implementationen können sich dort anders verhalten, allerdings sind mir solche nicht bekannt.

    Ich verwende Archlinux. Leider weiß ich nicht auf was Arch basiert.

    Arch basiert auf Arch ;-) - ist eine eigenständige Distribution die ohne eine bestehende Basis gebaut wird.


    Vielleicht wurde in Apache das Modul nicht einkompiliert.

    Eigentlich sollte das aber vorhanden sein: https://archlinux.org/packages/extra/x86_64/apache/files/


    Guck mal bitte, ob die Datei /usr/lib/httpd/modules/mod_proxy_wstunnel.so existiert.


    Mir würde eine Aussage von netcup reichen ob es sein kann das meine idle websocket Verbindung nach 60 Sekunden von netcup getrennt wird.

    Das kann ich auf jeden Fall ausschließen.

    Der Game-Client ist in c++ entwickelt und wird mit emscripten zu wasm compiliert.

    Das ist ja mal mega. :thumbup:

    Nutzt du diese API? https://emscripten.org/docs/po…p-sockets-over-websockets



    dann kommt eine Fehlermeldung das proxy_wstunnel nicht geladen ist

    Das ist echt ungewöhnlich.

    Eigentlich sollte es damit gehen:


    Code
    1. a2enmod proxy
    2. a2enmod proxy_http
    3. a2enmod proxy_wstunnel


    Gibt es einen Grund, warum du Apache nutzt?

    Es gibt viel bessere Proxies, z.B. nginx - der kann auch den Client ausliefern.


    Wenn Apache hier wirklich das Problem ist, würde ich es mit nginx probieren.

    Das könnte auch von der Performance interessanter werden.

    Ich habe aber noch nie mit Websockets unter nginx gearbeitet.

    Wie frank_m schon angedeutet hat ist das möglicherweise auch gar nicht mal die beste Lösung (?).

    Ich sehe das Problem nicht. Ggf. hat sich Frank da verguckt.

    Ich benutze hier immer ein Script, welches mir die Adressen zuweist, nachdem das Netzwerk durchlief.


    Die IPv6 kannst du doch auch in der LXC Config für die Bridge zuweisen - evtl. sogar direkt unter /etc/network/interfaces

    Die Bridge selbst steht nämlich solange auf "down", bis der erste Container gestartet ist. Und dieser Zeitpunkt kann halt nach "post up" von ens3 liegen.


    Ich würde sagen, da stimmt etwas in der Logik bzgl. der Startreihenfolge nicht.

    Hallo werto87 und herzlich Willkommen im Forum,


    der Editor unter dem Forum hat bestimmte Funktionen für Quelltexte etc.

    Bitte nutze diese Funktionen für Config Dateien und Logs - das macht deinen Beitrag übersichtlicher.


    Mir fehlt auch ein bisschen die Beschreibung, was du da eigentlich vor hast.

    Das Serverprogramm, ist das selbstentwickelt?


    Und du möchtest mit dem Apache einen Websocket als Proxy anbinden, verstehe ich das richtig?


    Zur eigentlichen Problemlösung:

    - Hast du im Apache das Modul proxy_wstunnel geladen?

    - Was macht denn der Client (Webbrowser)? Gibt es dort nicht auch Keepalive Optionen?

    - In einigen Quellen steht auch was davon, dass einige Browser damit Probleme machen und ein Wechsel des Browsers die Probleme löst. Damit könntest du ausschließen, dass der Server das Problem ist.

    Als Gateway nutze ich die Public-Adresse die ich der lxcbr0 Bridge zugewiesen habe. fe80::1 funktioniert hier leider (noch) nicht.

    Auf dem Host: ip -6 addr add fe80::1 dev lxcbr0 - dann kannst du im Container auch fe80::1 als Gateway eintragen.


    Für die initiale Verzögerung hatte ich bisher auch keine Lösung gefunden. Der Ping ist aber ein guter Workaround.

    Was nutzt ihr denn so als täglichen Browser?

    Firefox - sowohl auf dem Linux Desktop, als auch auf Android. Das letzte UI Update konnte man ja gottseidank per about:config deaktivieren.


    Chrome & Chromium wollen immer noch beim Start den Gnome Keyring entsperren. Mitlerweile halten sie sich sogar an das Fensterlayout vom Window Manager.

    IP-Adressen, Zugriffszeitpunkte und sonstige Metadaten bei der DNS-Auflösung sind also keine "Daten"?

    Diese Daten kann jeder authoritative DNS Server sammeln, sprich jeder Domainbetreiber.

    Da das ganze sogar unverschlüsselt auf Port 53 abläuft, haben diese Daten dann nicht nur Cloudflare, Google, IBM, sondern auch:

    - dein Internetanbieter (Telekom, Vodafone, O2...)

    - alle die dazwischen schnorcheln: Cisco, Huawei, HE, Juniper, Palo Alto


    Diese Daten fällen für jede Domain egal bei welchem Anbieter an.

    Das ist eigentlich kein Argument gegen einen authoritativen DNS Anycast Anbieter.



    Und selbst wenn das für einen soweit alles passt, gibt es ausreichend Gründe auf CloudFlare zu verzichten.

    Das betrifft jedoch nur den Proxy und die Public Resolver, nicht aber den authoritativen Dienst.

    Klar kann man das in Betracht ziehen, wenn man Cloudflare boykottieren möchte.


    Für die sachliche Diskussion über den authoritativen Dienst spielt das aber keine Rolle - die Gründe sind in dem Fall ad hominem Argumente.


    Was hier noch iO ist, sind die US Geheimdienste - diese sind aber genauso bei Huricane Electric präsent, wo viele aus der Netcup Community sekundäre DNS Server betreiben. Komischerweise steht da nix vonwegen Datensicherheit in den entsprechenden Threads.


    Ich möchte einfach nur, dass die Diskussion (um Cloudflare) sachlich bleibt.