Dauert noch so ungefähr -4 Monate
Das längste Thema
- fLoo
- Unerledigt
-
-
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.
-
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.
-
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? In https://www.rfc-editor.org/wp-…ds/rfc-editor-process.gif von https://www.rfc-editor.org/pubprocess/ kommt WIP nicht vor?
-
WIP?
ZitatDas 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…
Code
Alles anzeigen# Einmal von extern (Thunderbird) – wo es sowieso immer klappte. dovecot: submission-login: Login: user=<user@example.net>, method=PLAIN, rip=2001:db8::2, lip=2001:db8::1, mpid=4500, TLS, TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) postfix/dovecot-submission/smtpd[2589]: connect from postfix.local[fefe::ac1f:2801] postfix/dovecot-submission/smtpd[2589]: disconnect from postfix.local[2001:db8::2] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 […] # Und einmal von intern (Roundcube) – wo es bisher nicht klappte! dovecot: submission-login: Login: user=<user@example.net>, method=LOGIN, rip=::1, lip=::1, mpid=5467, secured postfix/dovecot-submission/smtpd[2589]: connect from postfix.local[fefe::ac1f:2801] postfix/dovecot-submission/smtpd[2589]: disconnect from postfix.local[::1] ehlo=2 xclient=0/1 mail=1 rcpt=1 data=1 quit=1 commands=6/7
Damit ich es nicht vergesse:
Code: /etc/network/interfacesiface lo inet loopback up ip -4 addr add 172.31.40.1/32 dev lo down ip -4 addr del 172.31.40.1/32 dev lo up ip -6 addr add fefe::ac1f:2801/128 dev lo preferred_lft 0 down ip -6 addr del fefe::ac1f:2801/128 dev lo
Code: /etc/postfix/master.cfpostfix.local:24 inet n - y - - smtpd […] -o smtpd_authorized_xclient_hosts=172.31.40.1/32,[fefe::ac1f:2801]/128
Code: /etc/roundcube/config.inc.php$config['smtp_server'] = 'localhost'; $config['smtp_port'] = 587;
Zusammengefasst: dovecot-submissiond verbindet nun nicht mehr zu localhost:24, sondern zu postfix.local:24.
Roundcube (und andere lokale Scripte) können wie gewohnt über localhost:587 Mails mit vorheriger Authentifizierung einliefern.
Dadurch gibt es kein Problem mehr, da 127.0.0.1 bzw. ::1 nicht mehr der freigegebene XCLIENT ist. Die Adresse darf somit gesetzt werden.
postfix.local:24 muss natürlich, wie vorher schon der Port auf localhost, in der Firewall für den Zugriff gesperrt werden, damit nur der vmail-User Zugriff hat.
-
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;
-
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
-
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
-
Dein Problem findest du unter https://hicu.be/bridge-vs-macvlan bzw. https://docs.oracle.com/cd/E37…5/html/ol_mcvnbr_lxc.html wieder, ebenso Lösungsansätze.
-
Ende des Jahres soll TeamSpeak 5 erscheinen. Bin mal gespannt, was das wird.
-
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
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;
¹ das war das Zeitalter der digitalen Papierflut
(andere bezeichnen es auch das 'Paläolithikum der IT')
-
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.
-
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.
-
Vielleicht gibt es dann die nächste electron.js App. Ich will nicht wissen, wie viele Chromium Binaries ich schon auf dem Rechner habe.