B.t.w.: Your internet fits in my subnet…. IPv6, new world order.
Fragen? Einfach melden.
Kategorie: Netzwerke & Protokolle (Seite 5 von 5)
IPv4, IPv6, DNS, DNSSEC, SSH und Netzwerk-Grundlagen — Praxiswissen für Admins und Netzwerker.
RIPE ist in Sachen IPv4 Adressen nun soweit leer dass sie nun auf ein „erweitertes“ Vergabeverfahren wechseln. Soll bedeuten dass nun ganz super streng (bla bla bla) kontrolliert wird warum und wo die Adresse hingeht und ob die auch wirklich gebraucht wird…..
Wie auch immer! Damit man sich besonders gut anschauen kann was noch übrig ist gibt es von den Jungs selbst eine kleine Grafik (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph).
Dass ich ein großer Freund davon bin, mal endlich mit IPv6 aus dem Arsch zu kommen, muss ich ja keinem mehr erzählen. Wenn ich mir andere Hochrechnungen anschaue (http://www.potaroo.net/tools/ipv4/index.html) dann haben wir aktuelle noch bis zum 24.09.2012 (das ändert sich noch mal) IPv4 Adressen.
Ja ja… IPv4 ist ab dem Tag nicht tot (Dualstack für die nächsten Jahre..) und unsere Provider und Hoster haben auch noch Reserven. Zusätzlich kann man ab dem Moment beginnen seine IPv4 Adressen zu verkaufen *lach*….. AAAABBBER, warum der ganze Stress? Warum nicht einfach mal mit IPv6 beschäftigen? Nein nein, ich meine wirklich beschäftigen, nicht nur so tun als ob.
Siehe auch: IPv4-Adressen sind aufgebraucht
Fragen? Einfach melden.
OpenSSH kann die Fingerprints seiner Host Keys als SSHFP-Records im DNS veröffentlichen. Beim Verbindungsaufbau prüft der Client dann automatisch, ob der Fingerprint des Servers mit dem DNS-Eintrag übereinstimmt, ein wirksamer Schutz gegen Man-in-the-Middle-Angriffe. Ist die Zone zusätzlich per DNSSEC gesichert, kann der DNS-Record selbst nicht gefälscht werden. Die Spezifikation steht in RFC 4255.
Client konfigurieren
Damit OpenSSH beim Verbindungsaufbau SSHFP-Records prüft, muss VerifyHostKeyDNS aktiviert werden. Global für alle Benutzer in /etc/ssh/ssh_config:
VerifyHostKeyDNS yes
Oder nur für die aktuelle Sitzung:
ssh -o "VerifyHostKeyDNS=yes" server.example.de
SSHFP-Records erzeugen
Am einfachsten direkt auf dem Server mit ssh-keygen, das erzeugt die fertigen DNS-Records für alle vorhandenen Host Keys:
ssh-keygen -r server.example.de.
Ausgabe (Beispiel mit RSA, ECDSA und Ed25519):
server.example.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148 server.example.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e3... server.example.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62 server.example.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1... server.example.de. IN SSHFP 4 1 a1b2c3d4e5f6... server.example.de. IN SSHFP 4 2 d4e5f6a7b8c9...
Aufbau des SSHFP-Records
Ein SSHFP-Record besteht aus zwei Zahlen und dem Fingerprint:
hostname IN SSHFP [Algorithmus] [Hash-Typ] [Fingerprint]
Algorithmus:
- 1, RSA
- 3, ECDSA
- 4, Ed25519 (empfohlen, ab OpenSSH 6.7)
DSS (2) ist seit OpenSSH 7.0 standardmäßig deaktiviert und sollte nicht mehr verwendet werden.
Hash-Typ: 1 = SHA-1, 2 = SHA-256. Beide sollten veröffentlicht werden, ältere Clients verstehen nur SHA-1, neuere bevorzugen SHA-256.
Prüfen
Mit dig lässt sich prüfen, ob die Records im DNS angekommen sind:
dig +short server.example.de SSHFP 1 1 47890EECC9A2893061734B07B8F60CAA1A856148 1 2 B2518AD49CC2ADF517D3F6A9FAAF4017ABC2C3E3... 3 1 3DD9DE0DCF1523341B45A53F1D57043609E26C62 4 2 D4E5F6A7B8C9...
Wichtig: Bei der DNSSEC-validierten Abfrage muss das ad-Flag (Authenticated Data) gesetzt sein, sonst ist die Antwort nicht vertrauenswürdig:
dig +dnssec server.example.de SSHFP | grep flags ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
Verbindungsaufbau mit SSHFP
Ohne SSHFP-Records im DNS meldet OpenSSH:
DNS lookup error: data does not exist No matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?
Mit SSHFP-Records und DNSSEC:
debug1: found 4 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS
secure bedeutet: Die DNS-Antwort wurde per DNSSEC validiert. Ohne DNSSEC steht dort insecure, der Fingerprint wurde zwar gefunden, aber der DNS-Antwort selbst kann nicht vertraut werden. Für echte Sicherheit braucht man beides: SSHFP-Records und DNSSEC.
Strenge Prüfung erzwingen
Optional: OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host Key erfolgreich validiert wurde:
Host *
VerifyHostKeyDNS yes
StrictHostKeyChecking yes
Damit wird die Verbindung abgelehnt, wenn kein passender SSHFP-Record gefunden wird oder die DNSSEC-Validierung fehlschlägt. Das ist die sicherste Einstellung, setzt aber voraus, dass alle Zielserver SSHFP-Records haben.
Kleiner Aufwand, viel mehr Sicherheit. Fragen? Einfach melden.
www.kernel-error.de (2001:7d8:8001:100:0:0:dead:beef) doesn’t have #IPv6 Path MTU Discovery problem.
Nur mal nebenbei…
www.kernel-error.de (2001:7d8:8001:100:0:0:dead:beef) doesn’t have #IPv6 Path MTU Discovery problem. http://hide.dnsalias.net/aaaa/pmtucheck.cgi/www.kernel-error.de/
Fragen? Einfach melden.
Warum vergessen nur immer alle die DNS Informationen zu ihrem neuen Jabber-Server zu setzten? Ich bin heute sicher zum 12 mal nach einem Problem gefragt worden welches damit zusammen hing. Die Info fehlt aber auch in _fast_ jedem Howto. Kopieren denn wirklich alle nur noch Zeile für Zeile? Als Wikipedia mal einen Tag ausgesetzt hat, konnten tausende keine Hausaufgaben abgeben. Irgendwie habe ich dass Gefühl, wenn Google mal einen Tag aussetzten würde könnten tausende „Admins“ nichts installieren oder Probleme lösen ;-P
Also um es noch mal in Google zu werfen:
Damit die Kommunikation zwischen den Jabber-Server sauber läuft müssen die nötigen DNS Records vorhanden sein. Für meinen Bind schaut es so aus wie im folgenden Beispiel:
_jabber._tcp.jabber.kernel-error.de. IN SRV 0 0 5269 jabber.kernel-error.de. _xmpp-server._tcp.jabber.kernel-error.de. IN SRV 0 0 5269 jabber.kernel-error.de. _xmpp-client._tcp.jabber.kernel-error.de. IN SRV 0 0 5222 jabber.kernel-error.de.
Testen lässt sich dieses am Ende natürlich mit dig:
$ dig SRV _xmpp-server._tcp.jabber.kernel-error.de +short 0 0 5269 jabber.kernel-error.de. $ dig SRV _xmpp-client._tcp.jabber.kernel-error.de +short 0 0 5222 jabber.kernel-error.de.
Fragen? Einfach melden.
Wie so oft führen viele Wege nach Rom. Damit Ejabberd auf der IPv4 und den IPv6 Adressen gleichzeitig lauscht hat sich für mich folgender als gut erwiesen:
In der Konfigurationsdatei: /etc/ejabberd/ejabberd.cfg
Im Abschnitt Listening Ports einfach in die Portkonfiguration inet4 sowie inet6 aufnehmen:
{5222, ejabberd_c2s, [
inet4,
inet6,
{access, c2s},
{shaper, c2s_shaper},
{max_stanza_size, 65536},
%%zlib,
starttls, {certfile, "/etc/ejabberd/ejabberd.pem"}
]},
Schon arbeitet Ejabberd mit beiden:
# netstat -an|grep 5222 tcp6 0 0 :::5222 :::* LISTEN tcp6 0 0 *:5222 *:* LISTEN
Ach ja, Ejabberd Version ist gerade: 2.1.5
Fragen? Einfach melden.
Meine IPv6-Reise begann 2003. Damals kam IPv6 vom eigenen ISP nicht in Frage, also ging es über einen Tunnelbroker. SixXS stellte kostenlos IPv6-Tunnel bereit und vergab auf Antrag sogar ein komplettes /48 Netz. SixXS wurde 2017 eingestellt, aber die Grundlagen von IPv6 haben sich nicht geändert. Heute liefern die meisten ISPs IPv6 nativ aus.
Adressformat
IPv6-Adressen sind 128 Bit lang. Das sind 2128 mögliche Adressen, ausgeschrieben: 340.282.366.920.938.463.463.374.607.431.768.211.456. Geschrieben werden sie hexadezimal, jeweils zwei Bytes durch Doppelpunkt getrennt:
2a01:0198:0200:0945:0000:0000:0000:0002
Führende Nullen darf man weglassen. Ein zusammenhängender Block aus Nullen kann einmal durch :: ersetzt werden:
# Führende Nullen weg 2a01:198:200:945:0:0:0:2 # Ein Nullblock durch :: ersetzt 2a01:198:200:945::2 # Als Netz 2a01:198:200:945::/64
Wichtige Adressen
::1 ist der Localhost. fe80::/10 sind Link-Local-Adressen, die jedes Interface automatisch bekommt. ff02::1 erreicht alle Hosts im lokalen Netz, ff02::2 alle Router. 2001:db8::/32 ist für Dokumentation reserviert.
# Alle Hosts im lokalen Netz anpingen ping6 -I eth0 ff02::1 # Alle Router im lokalen Netz anpingen ping6 -I eth0 ff02::2
Adressbildung und EUI-64
Link-Local-Adressen bildet der Host selbst aus dem Prefix fe80 und der MAC-Adresse im EUI-64 Format. Die MAC-Adresse hat 48 Bit, EUI-64 erweitert sie auf 64 Bit. Zusammen mit dem 64-Bit-Prefix ergibt das die vollen 128 Bit. IPv6 ist damit bereits auf 64-Bit-MAC-Adressen vorbereitet, falls die 48-Bit-Adressen irgendwann knapp werden. Duplicate Address Detection (DAD) stellt sicher, dass keine Adresse doppelt vergeben wird.
Autokonfiguration mit radvd
ARP wurde durch Neighbor Discovery (ND) ersetzt. IPv6 ist auf Autokonfiguration ausgelegt. Ein Router Advertisement Daemon (radvd) teilt allen Hosts im Netz das IPv6-Prefix mit. Die Hosts bilden sich ihre Adresse selbst. Kein DHCP nötig für die Grundkonfiguration.
Forwarding aktivieren und radvd konfigurieren:
echo 1 > /proc/sys/net/ipv6/conf/default/forwarding
# /etc/radvd.conf
interface eth0
{
AdvSendAdvert on;
AdvLinkMTU 1280;
MaxRtrAdvInterval 300;
prefix 2a01:198:200:945::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
Nach dem Start von radvd holen sich alle Hosts im Netz automatisch eine Adresse aus dem Prefix. Prüfen mit:
ip addr show eth0
Kein NAT mehr
Mit IPv6 ist NAT nicht mehr nötig. Jedes Gerät bekommt eine eigene öffentliche Adresse. Das bedeutet aber auch: Jedes Gerät ist direkt aus dem Internet erreichbar. Eine Firewall ist Pflicht. IPv6 hat einen eigenen Paketfilter, ip6tables statt iptables. Wer iptables kennt, kann auch ip6tables.
Über die Probleme die durch fehlende IPv6-Unterstützung bei Diensteanbietern entstehen habe ich separat geschrieben.
Hurricane Electric IPv6 Zertifizierung
Hurricane Electric bietet eine kostenlose IPv6-Zertifizierung an. Man arbeitet sich durch verschiedene Levels, vom ersten Tunnel bis zum voll IPv6-fähigen Mailserver. Am Ende gibt es ein T-Shirt.
Fragen? Einfach melden.