Das längste Thema

  • Dauert noch so ungefähr -4 Monate. TLS 1.3 ist schon seit Ende März 2018 freigegeben.

    Wenn ich das richtig sehe ist es seit Ende März ein Entwurf, der im September ausläuft ;) https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Seite 1 "Status of this memo"

    Also mitnichten "offiziell freigegeben"


    Vielleicht n bisschen mehr informieren bevor man bissige Kommentare ablässt.

    Code
    It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
  • Wenn ich das richtig sehe ist es seit Ende März ein Entwurf, der im September ausläuft ;)

    Afaik wird die finale Version genau wie Draft 28 sein. Warum es noch immer kein offizielles und finales RFC-Dokument gibt, ist eine andere Frage.


    Bevor das nicht draußen ist, wird es allerdings sicher kein Release von OpenSSL 1.1.1 geben.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Afaik wird die finale Version genau wie Draft 28 sein. Warum es noch immer kein offizielles und finales RFC-Dokument gibt, ist eine andere Frage.

    Ich glaube durch das "Auslaufen" des Drafts (am 21. September dann) entsteht automagisch der "fertige" RFC. Bis dahin ist quasi die Frist noch Änderungen einzubringen. Das Dokument bezeichnet sich selbst halt als WIP, weshalb ich es fragwürdig finde zu sagen, dass es schon offiziell "draußen" ist.

    Ok, das ist kompletter Blödsinn. Hier der aktuelle Stand: https://www.rfc-editor.org/auth48/C357

  • WIP?

    Zitat

    Das Dokument bezeichnet sich selbst halt als WIP

    It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

    Aber danke für das gute Bild. Hatte mich selbst bisher nicht mit dem Prozess ansich auseinander gesetzt.

    Habe oben meine Antwort auch noch editiert gehabt mit dem aktuellen Status (AUTH48)

  • Typisches Hairpin Problem. Entweder du rufst intern auch über interne IPs auf, oder du machst es wie ich und setzt einen internen DNS Recursor ein.

    Joa, das ist leider alles nicht "transparent" für Layer 3 -> an der Applikation/Container rumpfuschen, was ich vermeiden will.


    Gibt es irgendne Lösung, die Pakete von "innen" also Masquerade wieder als "von außen" ins DNAT einzuspeisen? Also alles was von vmbr an die IP vom eth0 kommt soll behandelt werden, als käme es von eth0 von außen?


    Viele Grüße

    margau

  • margau bei mir auf den Heimservern ist die Host-Gast Kommunikation ein Feature des Switches. Es werden nämlich die Pakete ins physikalische Netz entlassen und wenn der Switch dann erkennt, das die Kommunikation wieder zurück an den Quellport muss und das auch unterstützt, dann funktioniert das ganze reibungslos. So habe ich das mal gelesen.

  • Es gibt nur ein Problem, das ich nicht gelöst bekomme: Lokale Scripte (wie z.B. Roundcube) können zwar zu dovecot-submissiond verbinden und sich erfolgreich authentifizieren, danach dreht allerdings Postfix durch und verweigert den Versand, weile er behauptet, dass man nicht eingeloggt ist.

    Und es geht doch, mit einem kleinen Umweg… 8o

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • margau bei mir auf den Heimservern ist die Host-Gast Kommunikation ein Feature des Switches. Es werden nämlich die Pakete ins physikalische Netz entlassen und wenn der Switch dann erkennt, das die Kommunikation wieder zurück an den Quellport muss und das auch unterstützt, dann funktioniert das ganze reibungslos. So habe ich das mal gelesen.

    Hallo, auf Layer 2 ist das bei mir auch kein Problem. Problematischer ist, dass auf Layer 3 für Iptables entsprechend umgebogen zu bekommen.


    Klar, eine Lösung wäre DNAT und SNAT für jede beliebige IP/Port Kombination - aber das will ja auch keiner konfigurieren...

    Viele Grüße

    margau

  • Hat man f. diesen Zweck nicht analog wie bei VMware virtuelle Netzwerkadapter am Host?


    das von Dir H6G beschriebene ist bei VMware der sogenannte Bridged-Mode,

    und hier ist man im selben Netzwerk wie der Host selbst; da gibt es auf Layer 3 kein NAT;


    das von Dir margau gewünschte wäre bei VMware über dieses NAT-Netzwerkdevice;


    und das andere virtuelle Netzwerkdevice bei VMware ist f. Hostonly; sprich hier besteht nur zwischen

    dem VMware Host und VMware Guest eine Netzwerkverbindung;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Hallo,

    nochmal zum klarstellen:

    vmbr0 ist WAN, hat eine Public IP.

    Die Gäste sind im vmbr1, und haben private IPs. Im host findet iptables-NAT von vmbr1 auf vmbr0 (ausgehend) statt.

    Das, was bei vmbr0 ankommt, wird portbasiert per DNAT auf den richtigen Container weitergeleitet.


    Das Problem ist, wenn ein Container aus vmbr1 über die öffentlichen IP wie alle anderen Zugreifen will, das Paket also eigentlich per DNAT angefasst werden muss.


    Viele Grüße

    margau

  • Das Problem ist, wenn ein Container aus vmbr1 über die öffentlichen IP wie alle anderen Zugreifen will, das Paket also eigentlich per DNAT angefasst werden muss.

    äh, die Container untereinander verwenden doch keine öffentliche IP, ebenso die Verbindungen zwischen Container¹ und Host nicht;

    ein Port steht am Host nur einmal zur Verfügung, entweder direkt am Host selbst oder durch Port-Weiterleitung auf einem der Container¹;


    wo ist jetzt das Problem?


    ¹ meint hier wahrscheinlich Guest

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Es sind LXC-Container, die aber einzelne Guests sind. Das Problem ist folgendes: Portweitereitung am Host ganz normal eingerichtet (80->10.0.0.1, etc.). Container 2 will jetzt example.com aufrufen. Example.com liegt auf demselben Host wie Container 2 -> Paket bleibt beim Host an der Innenseite "hängen".

    Und wenn die Portweiterleitung auch von innen doch funktioniert, passiert folgendes:

    1.1.1.1 ist die öffentliche IP des Hosts (A von example.com)

    10.1.1.1 ist Container mit Dienst

    10.1.1.2 ist anfragender Container

    1.1.1.1 hat DNAT auf 10.1.1.1 für Port 80...


    10.1.1.2 sendet Paket an 1.1.1.1, durch DNAT geht es an 10.1.1.1.

    10.1.1.1 sieht Paket von 10.1.1.2, und sendet Antwort über die Bridge zurück. 10.1.1.2 bekommt Antwort von 10.1.1.1, kann aber nix damit anfangen, da die Antwort von 1.1.1.1 kommen müsste.


    Ich hoffe ich konnte das Problem etwas besser erklären ;)


    Viele Grüße

    margau

  • H6G vielleicht kommt das längst überfällige Massenanruffeature;

    das schafft nicht mal das primitive Telephon;

    die Reklameungeheuer konnten das schon immer,

    sogar in der Hundehütte landet das:D


    das erinnert mich irgendwie an die Volkszählung vor x Tausend Jahren¹,

    da bekam mein Onkel 24 'Personen'-Bögen zum ausfüllen;

    nur wie komisch war das ein 4 Personen-Haushalt mit

    20 Rindviechern (= Paarhufer) im Stall;:D


    ¹ das war das Zeitalter der digitalen Papierflut:D

    (andere bezeichnen es auch das 'Paläolithikum der IT')

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Es sind LXC-Container, die aber einzelne Guests sind. Das Problem ist folgendes: Portweitereitung am Host ganz normal eingerichtet (80->10.0.0.1, etc.). Container 2 will jetzt example.com aufrufen. Example.com liegt auf demselben Host wie Container 2 -> Paket bleibt beim Host an der Innenseite "hängen".

    [..]

    Wir haben das Problem bei uns dadurch "gelöst", indem ich im LXD DNS CNAMEs für die betroffenen Container eingerichtet habe, die untereinander kommunizieren müssen. Nicht hübsch, erfüllt aber seinen Zweck. Erfordert allerdings manuellen Aufwand.


    Code
    LXD network bridge DNS alias: (lxc network edit lxdbr0)
        raw.dnsmasq: |-
            cname=mailcow.example.com,mailcow.lxd
            cname=stream.example.com,icecast-public.lxd
            cname=direct.example.com,ajenti.lxd
  • Ende des Jahres soll TeamSpeak 5 erscheinen. Bin mal gespannt, was das wird.

    Kann man das ganze dann auch ohne Client-Software im Browser verwenden, wie der Konkurrent Discord das vorgemacht hat?


    Mittlerweile verwenden immer weniger Leute Teamspeak, bin aber gespannt, was die Version 5 dann können wird.