Datenhaufen zu IT und Elektronik.

Kategorie: Netzwerke & Protokolle (Seite 2 von 5)

DoH (DNS over HTTPS) mit BIND auf eigenem Server

Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.

Meine Tests mit DoT (DNS over TLS) habe ich bereits vor einiger Zeit gestartet.  DoT DNS over TLS mit Bind, stunnel und Android 9 Dieses arbeitet noch immer ganz fein auf meinem Smartphone. DoT gefällt mir noch immer um einiges besser als DoH aber auch hier wollte ich nun einmal einen Versuch starten. Zusammen mit nginx und einem etwas angepassten doh-proxy läuft dieses nun auf dem gleichen System.

Im Firefox ist es schnell aktiviert https://ns1.kernel-error.de/dns-query…

DoH DNS over HTTPS Firefox

Es funktioniert auch, so richtig glücklich macht es mich aber nicht! Natürlich ist die Umsetzung nur etwas für einen kleinen privaten Test. „Schnell“ genug ist es ebenfalls! Zumindest zum Surfen im Internet, dennoch wäre mir eine saubere Implementierung von DoT im resolver vom OS viel lieber. So wie bereits ab Android 9 zu sehen. Vielleicht ändert sich mein Gefühl ja etwas zusammen mit QUIC (HTTP/3)?!?

DNS over TLS (DoT) mit BIND, Stunnel und Android 9 einrichten

Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.

Die eigenen DNS Anfragen über eine Verschlüsselte Verbindung an einen DNS Server zu schicken welchem man vertraut, dieses liest sich schon gut oder? Keiner verfolgt mein Surfverhalten und zusammen mit DNSSEC schiebt mir so schnell keiner falsche Records unter 🙂

Am ehesten vertraue ich meinem eigenen DNS Server (ns1.kernel-error.de). Auf diesem arbeitet ein Bind und vor diesen habe ich für DoT stunnel gestellt. Die Konfiguration vom stunnel sieht dabei grob wie folgt aus:

[dns4]
accept = 853
connect = 127.0.0.1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt
ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
options = NO_SSLv2
options = NO_SSLv3
options = NO_TLSv1
options = NO_TLSv1.1
options = CIPHER_SERVER_PREFERENCE
options = DONT_INSERT_EMPTY_FRAGMENTS
renegotiation = no
TIMEOUTclose = 0

[dns6]
accept = 2a03:4000:38:20e::53:853 connect = ::1:53 cert = /usr/local/etc/stunnel/ssl/dns.crt key = /usr/local/etc/stunnel/ssl/dns.key CAfile = /usr/local/etc/stunnel/ssl/ca.crt ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 options = NO_SSLv2 options = NO_SSLv3 options = NO_TLSv1 options = NO_TLSv1.1 options = CIPHER_SERVER_PREFERENCE options = DONT_INSERT_EMPTY_FRAGMENTS renegotiation = no 

Die TLS Konfiguration ergibt dabei nun folgendes Bild: https://tls.imirhil.fr/tls/ns1.kernel-error.de:853

Auf einem Android 9 Gerät kann ich also nun unter den Einstellungen ==> Netzwerk & Internet ==> Erweitert ==> Privates DNS meinen Nameserver eintragen.

Screenshot der Konfigurationseinstellungen für DoT auf einem Android 9.

Jetzt sieht mir keiner mehr beim meinen DNS Abfragen zu 😀

FreeBSD als IPsec/L2TP-Client für Microsoft Windows Routing und RAS VPN

FreeBSD IPsec L2TP Client to Microsoft Windows Routing RAS Server Diagramm.

Vor einigen Monaten habe ich meinen FreeBSD (damals noch 11 heute 12) Desktop an einen Microsoft Windows Routing und RAS VPN Server angebunden. Das eingesetzte VPN war ein IPsec L2TP. Heute schaffe ich es endlich das Thema mal wegzuschreiben. Grob gesehen ist dieses der Aufbau.

Der FreeBSD Desktop hat dabei die IPv4 Adresse 192.168.10.57, der Windows Routing RAS VPN Server hat den FQDN vpnserver.domain.tld mit der IPv4 88.88.88.88 und der IPsec Tunnel hat den Namen vpnname. Die Netze im Unternehmen sind 172.16.0.0/12 und 10.0.0.0/8.

Tunneltyp ist ein IPsec L2TP an dem Windows „Ding“ mit PSK für den IPsec Tunnel und normaler Dämenenanmeldung über L2TP.

Auf meinem FreeBSD Desktop brauche ich also ipsec für den Tunnel und ich nutze mpd5 für L2TP. Ich „glaube“ l2tpd wäre vielleicht etwas besser, da mpd5 etwas manuelle Arbeit benötigt. Da ich an ein paar anderen Stellen ebenfalls mpd5 nutze und hier ohne Windows auch keine Handarbeit mehr nötig ist…. Es geht mir halt leichter von der Hand 🙂 Insg. ist die gesamte Konfiguration aber sehr einfach.

Meine ipsec Konfiguration sie wie folgt aus:

/usr/local/etc/ipsec.conf

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

#config setup
	# strictcrlpolicy=yes
	# uniqueids = no

# Add connections here.

# Sample VPN connections

#conn sample-self-signed
#      leftsubnet=10.1.0.0/16
#      leftcert=selfCert.der
#      leftsendcert=never
#      right=192.168.0.2
#      rightsubnet=10.2.0.0/16
#      rightcert=peerCert.der
#      auto=start

#conn sample-with-ca-cert
#      leftsubnet=10.1.0.0/16
#      leftcert=myCert.pem
#      right=192.168.0.2
#      rightsubnet=10.2.0.0/16
#      rightid="C=CH, O=Linux strongSwan CN=peer name"
#      auto=start

config setup

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev1
        authby=psk

conn vpnname
        type=transport
        leftfirewall=yes
        right=vpnserver.domain.tld
        rightid = %any
        rightsubnet=0.0.0.0/0
        auto=add
        left=%defaultroute
        leftprotoport=17/%any
        rightprotoport=17/1701
        ike=3des-sha1-modp1024!
        esp=3des-sha1
        modeconfig=push

Der PSK steht in der /usr/local/etc/ipsec.secrets

# ipsec.secrets - strongSwan IPsec secrets file
vpnserver.domain.tld %any : PSK "abcdefg1234567"

Den IPsec Tunnel baut man nun einfach wie folgt auf:

root@errortest:~ # ipsec up vpnname
initiating Main Mode IKE_SA vpnname[20] to 88.88.88.88
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.10.57[500] to 88.88.88.88[500] (176 bytes)
received packet: from 88.88.88.88[500] to 192.168.10.57[500] (208 bytes)
parsed ID_PROT response 0 [ SA V V V V V V ]
received MS NT5 ISAKMPOAKLEY vendor ID
received NAT-T (RFC 3947) vendor ID
received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
received FRAGMENTATION vendor ID
received unknown vendor ID: fb:1d:e3:cd:f3:41:b7:ea:16:b7:e5:be:08:55:f1:20
received unknown vendor ID: e3:a5:96:6a:76:37:9f:e7:07:22:82:31:e5:ce:86:52
selected proposal: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.10.57[500] to 88.88.88.88[500] (244 bytes)
received packet: from 88.88.88.88[500] to 192.168.10.57[500] (260 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 192.168.10.57[4500] to 88.88.88.88[4500] (68 bytes)
received packet: from 88.88.88.88[4500] to 192.168.10.57[4500] (68 bytes)
parsed ID_PROT response 0 [ ID HASH ]
IKE_SA vpnname[20] established between 192.168.10.57[192.168.10.57]...88.88.88.88[88.88.88.88]
scheduling reauthentication in 3402s
maximum IKE_SA lifetime 3582s
generating QUICK_MODE request 2082742542 [ HASH SA No ID ID NAT-OA NAT-OA ]
sending packet: from 192.168.10.57[4500] to 88.88.88.88[4500] (220 bytes)
received packet: from 88.88.88.88[4500] to 192.168.10.57[4500] (212 bytes)
parsed QUICK_MODE response 2082742542 [ HASH SA No ID ID NAT-OA NAT-OA ]
selected proposal: ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ
CHILD_SA vpnname{38} established with SPIs c387d93f_i 4720cab6_o and TS 192.168.10.57/32[udp] === 88.88.88.88/32[udp/l2f]
connection 'vpnname' established successfully

Ob der IPsec Tunnel steht sieht man mit:

root@errortest:~ # ipsec statusall
Status of IKE charon daemon (strongSwan 5.7.1, FreeBSD 12.0-RELEASE-p3, amd64):
  uptime: 12 hours, since Apr 03 21:26:07 2019
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
  loaded plugins: charon aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf curve25519 xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic whitelist addrblock counters
Listening IP addresses:
  2003:88:53dd:a800:eef4:bbff:fe47:c54c
  fd00::eef4:bbff:fe47:c54c
  192.168.10.57
Connections:
      vpnname:  %any...vpnserver.domain.tld  IKEv1
      vpnname:   local:  [192.168.10.57] uses pre-shared key authentication
      vpnname:   remote: uses pre-shared key authentication
      vpnname:   child:  dynamic[udp] === 0.0.0.0/0[udp/l2f] TRANSPORT
Security Associations (1 up, 0 connecting):
      vpnname[20]: ESTABLISHED 14 seconds ago, 192.168.10.57[192.168.10.57]...88.88.88.88[88.88.88.88]
      vpnname[20]: IKEv1 SPIs: 8d3cfef7264b42cc_i* 0d322a1593a9db84_r, pre-shared key reauthentication in 56 minutes
      vpnname[20]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
      vpnname{38}:  INSTALLED, TRANSPORT, reqid 10, ESP in UDP SPIs: c387d93f_i 4720cab6_o
      vpnname{38}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 14 minutes
      vpnname{38}:   192.168.10.57/32[udp] === 88.88.88.88/32[udp/l2f]

Jetzt fehlt also nur noch L2TP, meine mpd5 Konfiguration sieht dabei so aus /usr/local/etc/mpd5/mpd.conf :

startup:
      # Set web self 127.0.0.1 5008
      # Set user vpntest vpntest admin
      # Set web open
log +ALL +EVENTS -FRAME -ECHO
default:
      load L2TP_client

L2TP_client:
    create bundle static B1
	set iface up-script /home/kernel/vpnname-up.sh
	set iface down-script /home/kernel/vpnname-down.sh
	set bundle enable crypt-reqd
	set bundle enable compression
	set bundle enable ipv6cp
	set ccp yes mppc
	set mppc no e40 e56
	set mppc yes e128 stateless
	set ipcp ranges 0.0.0.0/0 0.0.0.0/0
	set ipcp enable req-pri-dns
	set ipcp enable req-sec-dns
	set iface route 172.16.0.0/12
	set iface route 10.0.0.0/8
	set iface enable tcpmssfix



    create link static L1 l2tp
    set link action bundle B1
    set auth authname "AD-USERNAME"
    set auth password "AD-PASSWORD"
    set link max-redial 0
    set link mtu 1400
    set link keep-alive 20 75
    set link accept chap-msv2
	set link no pap eap


    set l2tp peer vpnserver.domain.tld
    open

Einfach starten mit:

root@errortest:/ # mpd5
Multi-link PPP daemon for FreeBSD

process 10142 started, version 5.8 (root@120amd64-quarterly-job-15 02:54  8-Feb-2019)
[B1] Bundle: Interface ng0 created
[L1] [L1] Link: OPEN event
[L1] LCP: Open event
[L1] LCP: state change Initial --> Starting
[L1] LCP: LayerStart
L2TP: Initiating control connection 0x800caa310 0.0.0.0 0 <-> 88.88.88.88 1701
L2TP: Control connection 0x800caa310 192.168.10.57 38844 <-> 88.88.88.88 1701 connected
[L1] L2TP: Incoming call #7540000 via control connection 0x800caa310 initiated
[L1] L2TP: Call #7540000 connected
[L1] Link: UP event
[L1] LCP: Up event
[L1] LCP: state change Starting --> Req-Sent
[L1] LCP: SendConfigReq #1
[L1]   ACFCOMP
[L1]   PROTOCOMP
[L1]   MRU 1500
[L1]   MAGICNUM 0x2d8654b6
[L1] LCP: SendConfigReq #2
[L1]   ACFCOMP
[L1]   PROTOCOMP
[L1]   MRU 1500
[L1]   MAGICNUM 0x2d8654b6
[L1] LCP: rec'd Configure Request #0 (Req-Sent)
[L1]   MRU 1400
[L1]   AUTHPROTO EAP
[L1]   MAGICNUM 0x74943399
[L1]   PROTOCOMP
[L1]   ACFCOMP
[L1]   CALLBACK 6
[L1]   MP MRRU 1614
[L1]   ENDPOINTDISC [LOCAL] 01 d0 15 a9 b4 71 4f f4 a0 97 8e 3c e4 ef 93 d7 00 00 0
[L1] LCP: SendConfigRej #0
[L1]   CALLBACK 6
[L1]   MP MRRU 1614
[L1] LCP: rec'd Configure Ack #2 (Req-Sent)
[L1]   ACFCOMP
[L1]   PROTOCOMP
[L1]   MRU 1500
[L1]   MAGICNUM 0x2d8654b6
[L1] LCP: state change Req-Sent --> Ack-Rcvd
[L1] LCP: rec'd Configure Request #1 (Ack-Rcvd)
[L1]   MRU 1400
[L1]   AUTHPROTO EAP
[L1]   MAGICNUM 0x74943399
[L1]   PROTOCOMP
[L1]   ACFCOMP
[L1]   ENDPOINTDISC [LOCAL] 01 d0 15 a9 b4 71 4f f4 a0 97 8e 3c e4 ef 93 d7 00 00 0
[L1] LCP: SendConfigNak #1
[L1]   AUTHPROTO CHAP MSOFTv2
[L1] LCP: rec'd Configure Request #2 (Ack-Rcvd)
[L1]   MRU 1400
[L1]   AUTHPROTO CHAP MSOFTv2
[L1]   MAGICNUM 0x74943399
[L1]   PROTOCOMP
[L1]   ACFCOMP
[L1]   ENDPOINTDISC [LOCAL] 01 d0 15 a9 b4 71 4f f4 a0 97 8e 3c e4 ef 93 d7 00 00 0
[L1] LCP: SendConfigAck #2
[L1]   MRU 1400
[L1]   AUTHPROTO CHAP MSOFTv2
[L1]   MAGICNUM 0x74943399
[L1]   PROTOCOMP
[L1]   ACFCOMP
[L1]   ENDPOINTDISC [LOCAL] 01 d0 15 a9 b4 71 4f f4 a0 97 8e 3c e4 ef 93 d7 00 00 0
[L1] LCP: state change Ack-Rcvd --> Opened
[L1] LCP: auth: peer wants CHAP, I want nothing
[L1] LCP: LayerUp
[L1] CHAP: rec'd CHALLENGE #0 len: 26
[L1]   Name: "VPN-SERVER"
[L1] CHAP: Using authname "AD-USERNAME"
[L1] CHAP: sending RESPONSE #0 len: 60
[L1] CHAP: rec'd SUCCESS #0 len: 46
[L1]   MESG: S=39CCB87E756B7996C5A261EEC4CA14D30E4616E0
[L1] LCP: authorization successful
[L1] Link: Matched action 'bundle "B1" ""'
[L1] Link: Join bundle "B1"
[B1] Bundle: Status update: up 1 link, total bandwidth 64000 bps
[B1] IPCP: Open event
[B1] IPCP: state change Initial --> Starting
[B1] IPCP: LayerStart
[B1] IPV6CP: Open event
[B1] IPV6CP: state change Initial --> Starting
[B1] IPV6CP: LayerStart
[B1] CCP: Open event
[B1] CCP: state change Initial --> Starting
[B1] CCP: LayerStart
[B1] IPCP: Up event
[B1] IPCP: state change Starting --> Req-Sent
[B1] IPCP: SendConfigReq #1
[B1]   IPADDR 0.0.0.0
[B1]   COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
[B1]   PRIDNS 0.0.0.0
[B1]   SECDNS 0.0.0.0
[B1] IPV6CP: Up event
[B1] IPV6CP: state change Starting --> Req-Sent
[B1] IPV6CP: SendConfigReq #1
[B1] CCP: Up event
[B1] CCP: state change Starting --> Req-Sent
[B1] CCP: SendConfigReq #1
[B1]   MPPC
[B1]     0x01000040:MPPE(128 bits), stateless
[B1] IPV6CP: rec'd Configure Request #4 (Req-Sent)
[B1] IPV6CP: SendConfigAck #4
[B1] IPV6CP: state change Req-Sent --> Ack-Sent
[B1] CCP: rec'd Configure Request #5 (Req-Sent)
[B1]   MPPC
[B1]     0x01000001:MPPC, stateless
[B1] CCP: SendConfigNak #5
[B1]   MPPC
[B1]     0x01000040:MPPE(128 bits), stateless
[B1] IPCP: rec'd Configure Request #6 (Req-Sent)
[B1]   IPADDR 10.16.100.13
[B1]     10.16.100.13 is OK
[B1] IPCP: SendConfigAck #6
[B1]   IPADDR 10.16.100.13
[B1] IPCP: state change Req-Sent --> Ack-Sent
[B1] IPCP: rec'd Configure Reject #1 (Ack-Sent)
[B1]   COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
[B1] IPCP: SendConfigReq #2
[B1]   IPADDR 0.0.0.0
[B1]   PRIDNS 0.0.0.0
[B1]   SECDNS 0.0.0.0
[B1] IPV6CP: rec'd Configure Ack #1 (Ack-Sent)
[B1] IPV6CP: state change Ack-Sent --> Opened
[B1] IPV6CP: LayerUp
[B1]   eef4:bbff:fe47:c54c -> e467:e46a:5b1f:dfc1
[B1] IFACE: Up event
[B1] CCP: rec'd Configure Ack #1 (Req-Sent)
[B1]   MPPC
[B1]     0x01000040:MPPE(128 bits), stateless
[B1] CCP: state change Req-Sent --> Ack-Rcvd
[B1] CCP: rec'd Configure Request #7 (Ack-Rcvd)
[B1]   MPPC
[B1]     0x01000040:MPPE(128 bits), stateless
[B1] CCP: SendConfigAck #7
[B1]   MPPC
[B1]     0x01000040:MPPE(128 bits), stateless
[B1] CCP: state change Ack-Rcvd --> Opened
[B1] CCP: LayerUp
[B1] CCP: Compress using: mppc (MPPE(128 bits), stateless)
[B1] CCP: Decompress using: mppc (MPPE(128 bits), stateless)
[B1] IPCP: rec'd Configure Nak #2 (Ack-Sent)
[B1]   IPADDR 10.16.100.34
[B1]     10.16.100.34 is OK
[B1]   PRIDNS 10.16.0.53
[B1]   SECDNS 10.16.0.52
[B1] IPCP: SendConfigReq #3
[B1]   IPADDR 10.16.100.34
[B1]   PRIDNS 10.16.0.53
[B1]   SECDNS 10.16.0.52
[B1] IPCP: rec'd Configure Ack #3 (Ack-Sent)
[B1]   IPADDR 10.16.100.34
[B1]   PRIDNS 10.16.0.53
[B1]   SECDNS 10.16.0.52
[B1] IPCP: state change Ack-Sent --> Opened
[B1] IPCP: LayerUp
[B1]   10.16.100.34 -> 10.16.100.13

Ob alles steht sieht man ebenfalls mit ifconfig :

ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1396
	inet6 fe80::eef4:bbff:fe47:c54c%ng0 prefixlen 64 scopeid 0x3
	inet 10.16.100.34 --> 10.16.100.13 netmask 0xffffffff
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Damit sollte auch schon der Tunnel stehen.

Der Windows VPN Server übermittelt zwar eigentlich die Routen, DNS Server usw., dieses nimmt der mpd5 aber nicht alles gut an. Das meinte ich mit manueller Handarbeit. Sicher nichts für die Masse aber wenn man als Admin „ran“ möchte sicher kein größeres Problem. set ccp yes mppc activiert hierbei die MPPC Komprimierung und Verschlüsselung. set mppc yes e128 stateless ist dabei für die Zusammenarbeit mit dem Windows Server wichtig, denn e128 / stateless ermöglicht als einzige Option die Zusammenarbeit mit MS-CHAPv2 (was hier zum Einsatz kommt). Per IPCP frage ich zwar die Konfiguration wie die ersten beiden DNS-Server ab ( set ipcp enable req-pri-dns / set ipcp enable req-sec-dns ), aktuell mache ich aber damit nichts. Diese Werte werden automatisch mit an die iface up-scripte/down-scripte übermittelt und könnten dort mitbenutzt werden, da ich nur eine solche Verbindung habe und die DNS Konfiguration kenne, nutze die die up/down-scripte nur um die jeweilige /etc/resolv.conf zu kopieren.

Mit den Routen ist es ähnlich, ich kenne die Routen und kann sie also einfach mitgeben: set iface route 172.16.0.0/12 / set iface route 10.0.0.0/8 diese Liste kann nach Belieben eingepasst werden.

Wie gesagt, alles sehr einfach und überschaubar.

Ich starte IPsec und in folge mpd5 meist von Hand, wenn ich es mal brauche, man kann aber auch alles per Dienst starten lassen oder sich irgendeinen Startknopf bauen.

Fragen? Dann fragen!

IPv6 ULA vs. IPv4: Priorisierung anpassen gemäß RFC 6724​

Allgemein sagt man das IPv6 immer vor IPv4 geht. IPv6 Verbindungen sollten also immer gegenüber IPv4 Verbindungen bevorzugt werden. Ich war also etwas erstaunt als ein Windows System mit konfiguriertem IPv6 ULA Netzwerk dauerhaft seine alte IPv4 Verbindung bevorzugte…

Alle Linux Systeme verhalten sich dagegen wie gewünscht. Eine kurze Suche förderte erst RFC 3484 und dann der ersetzende RFC 6724 zutage. Hier wird eine Tabelle definiert in welcher die Verschiedenen IPv6 Prefixe sowie das umgerechnete IPv4 Prefix ::ffff:0:0/96 sowie deren Priorisierung gegenübergestellt werden. Spannend ist dabei das in RFC 3484 die prefix policy wie folgt war:

1. IPv6 loopback
2. Native IPv6, ULAs, site-local, 6one
3. 6to4
4. IPv4compat
5. IPv5
6. Teredo

Dieses hat sich aber mit RFC 6724 in 2012 geändert zu:

1. IPv6 loopback
2. Native IPv6
3. IPv4
4. 6to4
5. Teredo
6. ULAs
7. site-local
8. 6bone
9. IPv6Combat

Früher war also alles besser? Naja… Wie man sehen kann wird inzwischen IPv4 for IPv6 ULA priorisiert. Öhm… Ich habe da jetzt Leute im Kopf die fragen wie man IPv6 bei seinem System abschalten kann, weil es ja nur Probleme macht *kopfschüttel*. 

Wie ändert man nun also die Priorisierung?

Auf einem Windows lässt sich diese Liste wie folgt bewundern:

netsh int ipv6 show prefixpolicies

Auf einem Linux steht alles in: /etc/gai.conf und man kann es bewundern mit:

ip -f inet6 addrlabel show

Bei einem FreeBSD bekommt man die Liste wie folgt:

# ip6addrctl
Prefix                          Prec Label      Use
::1/128                           50     0        0
::/0                              40     1  5580865
::ffff:0.0.0.0/96                 35     4        0
2002::/16                         30     2        0
2001::/32                          5     5        0
fc00::/7                           3    13        0
::/96                              1     3      300
fec0::/10                          1    11        0
3ffe::/16                          1    12        0

Apple… Bei Apple ist es etwas spezieller! Daher erstmal zur Frage: „Wie gebe ich ULA eine höhere Prio als IPv4, damit mein schön konfiguriertes IPv6 ULA Netzwerk auf benutzt wird?“.

Ganz einfach für Windows:

netsh interface ipv6 set prefixpolicy fc00::/7 37 13

Bei den anderen Systemen (bis auf Apple) klappt das sehr ähnlich. Das finden diese User auch ohne das es copy&paste fertig ist, hm?

Apple…. Die Jungs nutzen RFC 6555 (Happy Eyeballs). Puhhh Joar die Idee dahinter ist nicht schlecht. Grob gesehen ist es so: Bei den meisten anderen RFCs wird nach einem AAAA RR geschaut und im Zusammenspiel mit der Prefix Policy geschaut ob man eine IPv6 Verbindung aufbauen kann. Klappt dieses nicht gibt es einen Fallback auf IPv4. Dieses setzt also voraus, dass eine IPv6 Verbindung nicht zustande kommt. Es kann also mal passieren, dass es dauert! Happy Eyeballs (was eine Name für ein RFC?!?!?) baut die IPv4 und IPv6 Verbindung gleichzeitig auf wenn es einen AAAA RR gibt. Klappt dieses „gut“ bleibt es bei IPv6 sonst hat man ja direkt schon die IPv4 Verbindung offen. Damit werden Wartezeiten minimiert. Eine ULA Verbindung wird dabei leider nicht gegen IPv4 priorisiert 🙁

Fragen? Dann fragen!

Mein IPv6 Samsung/HP Problem wurde gelöst!

Ich bin absolut überrascht. Das gesammte Thema war für mich nach der letzten Kommunikation „erledigt“. In den nächsten Jahren hätte ich nicht mehr mit einer Veränderung gerechnet…

Da kam heute aus dem Nichts folgende E-Mail:

Hallo Herr van de Meer,
 
manchmal geschehen noch kleine Wunder. Ich habe heute ein .par File für unsere IPv6 Herausforderung bekommen und erfolgreich bei meiner Maschine testen können.
Es ist jetzt also auch mit Samsung Maschinen möglich, eine „saubere und korrekte IP Adresse“ zuzuweisen.
Wenn noch Bedarf besteht, stelle ich ihnen gerne ein Link zum Download zur Verfügung.
 
Beste Grüße nach Bonn

Ich habe natürlich diesen Patch angefragt, blitzartig bekommen und eingespielt.

macbook-s-meer:~ kernel$ ping6 -c3 fd00:118f:335:62::253
PING6(56=40+8+8 bytes) fd00:118f:335:42:c3:51f8:2949:1641 --> fd00:118f:335:62::253
16 bytes from fd00:118f:335:62::253, icmp_seq=0 hlim=63 time=0.884 ms
16 bytes from fd00:118f:335:62::253, icmp_seq=1 hlim=63 time=0.703 ms
16 bytes from fd00:118f:335:62::253, icmp_seq=2 hlim=63 time=0.718 ms

--- fd00:118f:335:62::253 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.703/0.768/0.884/0.082 ms

Das geht jetzt einfach! Das geht wirklich 🙂 Ich kann dem Drucker eine feste IP Adresse meiner Wahl geben.

TLS 1.3 für Postfix & Dovecot: Einrichtung und Konfiguration​

Sowohl mein Postfix als auch der Dovecot sprechen nun sauber TLS 1.3.

Wenn Postfix sowie Dovecot sauber gegen OpenSSL 1.1.1 gebaut sind fehlen nur zwei Configänderungen.

Dovecot spricht es meist sofort wenn man hier die minimale TLS Version ind der 10-ssl.conf:

ssl_min_protocol = TLSv1.1

Beim Postfix setzt man einfach die zu nutzenden TLS Versionen in der main.cf:

smtpd_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3

Schon spricht Postfix TLS 1.3 mit anderen Server und beide Dienste sind in der Lage dieses mit Clients zu sprechen!

Test für smtp:

$ openssl s_client -starttls smtp -crlf -connect smtp.kernel-error.de:25
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Test für imap:

$ openssl s_client -connect imap.kernel-error.de:993 -crlf
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

So sieht ein Logfile doch schon viel mehr nach 2019 aus, oder?

Feb 15 16:05:43 smtp postfix/smtp[7475]: Verified TLS connection established to mx1.freebsd.org[2610:1c1:1:606c::19:1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256

Bei Fragen, einfach fragen 🙂

Mein IPv6 Samsung/HP Problem geht weiter..

Die Antwort auf meine letzte Nachricht war schnell!

JSP-Framework sind Java-Serverseiten, die in SWS verwendet werden.
Bevor wir die Benutzereingaben von Java-Serverseiten auf unsere Backend-Module anwenden, wird geprüft, ob die angegebenen Werte die vordefinierten Anforderungen erfüllen, die für diese Werte festgelegt sind.
Der Kunde kann die angegebene IP-Adresse (fd00) nicht anwenden, da unsere in JSPs vorhandenen Validierungsprüfungen fehlschlagen, bevor der Wert an Backend-Module übergeben wird.
Das JSP-Framework und die Bibliotheken sind offene Frameworks und werden von unserer Firmware intern verwendet.
Dies bedeutet jedoch, dass wir das entsprechende JSP-Framework selbst nicht ändern oder ändern können.
Daher unterstützen unsere Geräte die eindeutige lokale Adressierungsfunktion nicht.
Der Workaround (it is recommended to use the link local address fe80:333:333:62::253 instead of the fd00:333:333:62::253 IPv6 address), den wir zur Verfügung gestellt haben, ist alles, was wir tun können.

Der vorgeschobene Grund JSP-Framework hält nicht mal bis zum Satzende. Ein ehrliches: „Ja das ist ein Problem, dieses ist uns aber im Moment egal weil das Problem weniger als 1% unserer Kunden haben und wenn sich dieses ändert schauen wir es uns an!“…. So etwas wäre noch immer nicht gut aber ehrlich. Der Grund JSP-Framework beleidigt mich zusätzlich!

Damit sind wir wohl am Ende mit dem Thema.

Ich brauche einen HP/Samsung Techniker – Update zum IPv6 Druckerproblem

Ihr erinnert euch sicher noch an das IPv6 Druckerproblem zwischen uns und HP/Samsung, oder? Es gibt ein kleines Updates zu dem Thema!

Betreff: RE: X4300 und IPv6
  
was ist aus der IPv6 Anfrage des Kunden geworden? Hat der Admin einen anderen Weg gefunden?
Wir hatten den Fall eskaliert und folgende Antwort bekommen:
 
JSP will successfully validate only following IPv6 address types in manual address box:1. Site local IPv6 addresses (With prefix fec0)2. Link local addresses with prefix fe803. Global unicast addresses with prefix
 
Das heißt zusammengefasst, dass der Kopierer nicht mit einer Unique Local Address (fd00 Präfix) arbeiten kann.
Ich würde mich freuen, wenn sie sich diesbezüglich nochmal bei uns melden, damit wir wissen, ob wir den Fall schließen können.
 
Danke und beste Grüße

fec0?!?!? Das war eine Idee aus 1995 welche 2004 aus guten Gründen mit RFC 3879 gekippt wurde. Der Drucker frisst also fe80 sauber per EUI-64 (oh was ein wunder), globale Adressen (ok, kann jemand sinnvolle und brauche Ansätze nennen warum man das tun sollte?!?) und Adressen die man seit knapp 15 Jahren nicht mehr benutzen sollte O_o

Mal sehen wie Samsung / HP nun darauf reagiert. Ich kann doch nicht der einzige auf diesem Planeten mit dem Problem sein. dieses JSP-Ding wird doch auf allen erdenklichen Netzwerkdruckern eingesetzt. Das muss doch noch jemandem auffallen, oder? Dieser Bug muss doch nur von einem Entwickler dort gelesen werden, der versteht was ich sage, dann macht er es schnell schön und gelöst ist das Problem. Ist da denn keiner?!?

IPv6 ULA und das SyncThru Web Service von Samsung / HP mögen sich nicht…

Inzwischen ist es kaum noch etwas Besonders von seinem ISP mit einem echten globalen IPv6 /64 beworfen zu werden. Dualstack bietet fast jeder an. Die meisten Dienste im Internet sind ebenfalls so erreichbar und fast jeder in der IT hat zumindest schon mal von IPv6 gehört.

Nicht ganz so bekannt sind anscheinend bei IPv6 die ULAs die Unique Local Addresses RFC 4193. Es ist der Bereich fc00::/7 und im speziellen der Bereich fd00::/8 ist bei IPv6 vergleichbar mit den alten bekannten 10.0.0.0/8, 172.16.0.0/12 und natürlich 192.168.0.0/16. Wenn mal also sein internes Netzwerk für IPv6 Aufbaut benutzt man diese Adressen.

Auf der Arbeit beschäftigen wir uns auch mit diesem Thema. Wir haben uns ein /48 gewürfelt, geplant wie wir verschiedene /56 daraus auf die verschiedenen Standorte verteilen bis am Ende in den verschiedenen Netzten ein /64 per RA herauskommt. Stück für Stück verteilen wir im Moment die einzelnen Netze und so bekommen immer wieder neue Systeme zu ihrer IPv4 Adresse auch eine IPv6 Adresse. Immer mal wieder stößt man selbst 2018 dabei noch auf Überraschungen. Die eine oder andere werde ich in der nächsten Zeit mit euch teilen.

Starten möchte ich heute mit unserer Samsung Printstation X4300LX. Diesem Drucker wollten wir die im zugedachte IPv6 ULA fest einstellen. Leider beantwortete der Drucker diesen Versuch immer nur mit: Make sure your input is correct. This field only allows IPv6 address

Gehen wir erst einmal auf das Thema fest einstellen ein, bevor dazu die ersten Mails kommen 😀

Bei IPv6 sollte der Client selbst sich darum kümmern eine Adresse zu haben. Selbst im kleinsten „sinnvollen“ IPv6 Netz (/64) gibt es so viele Adressen, dass bekannte zentrale Möglichkeiten schnell gestresst sein könnten. Daher bekommt der Client per RA Router Advertisement einige der nötigen Informationen um sich selbst eine Adresse zu basteln. Im Zusammenspiel mit der eigenen MAC Adresse kommt dann eine IPv6 Adresse zustande. Sofern diese Adresse nicht schon einmal im Netzwerk vertreten ist (dieses prüft der Client selbst per NDP Neighbor Discovery Protocol) hat der Drucker damit immer die selbe Adresse. Warum also selbst eine feste IPv6 Adresse am Drucker vergeben? Nun ja, für die Zeit der Umstellung ist es etwas einfacher wenn die IPv6 Adressen für uns Menschen etwas übersichtlicher sind. Die eigentlichen Benutzer kommen an keiner Stelle mit den Adressen in Berührung, sie nutzen ausschließlich den DNS Namen. Für uns Admins ist es dennoch etwas einfacher wenn gewisse zentale Systeme schon für uns an der IPv6 Adresse erkennbar sind. Zumindest solange wir noch im Aufbau des gesamten ULA Netzwerkes bei uns sind. Später wird dieses natürlich anders sein.

Zurück zum Drucker! Die eingegebene IPv6 Adresse ist natürlich gültig und absolut korrekt. Also haben wir uns an unseren Servicepartner für den Drucker gewendet. Hier ist IPv6 noch nicht so „weit“. Aussage war das wir die Ersten sind welche sich zu diesem Thema jemals gemeldet haben. Unser Servicepartner hat sich selbst noch etwas schlau gemacht und ist dann direkt in Kontakt mit Samsung / HP getreten. Die erste Rückmeldung die wir bekommen haben ist: Wenn wir das fd00 zum Beginn weglassen, dann könnten wir eine Adresse eintragen. Sie könnten dieses an verschiedenen Drucker so nachstellen. Zusammen sind wir dann zum Schluss gekommen, dass einfach die Adressüberprüfung vom Samsung SyncThru Web Service einen Bug hat. Unser Servicepartner ist also wieder in Kontakt mit seinem Ansprechparnter bei Samsung / HP getreten. Von diesem kam einige Zeit später eine E-Mail welche uns weitergeleitet wurde. In dieser E-Mail wird uns erklärt das IPv6 Adressen eindeutig sein sollten und wie sich aus der MAC Adresse eine IPv6 Adresse berechnet. Was natürlich absolut korrekt ist, unser eigentliches Problem nur leider nicht betrifft oder löst. Wir haben also wieder mit unserem Servicepartner gesprochen welcher uns wenig Hoffnung machte. Wenn Samsung / HP meint keinen Fehler gemacht zu haben wird es schwer ihnen das Gegenteil zu beweisen. Wir könnten dem Drucker ja einfach per DHCPv6 eine Adresse reservieren….

Joar könnten wir…. Wir haben einen zentralen DHCPv4 und auch einen zentralen DHCPv6 Server. Verschiedene DHCP-Relay Server leiten die Anfragen aus verschiedenen Netzten an diesen weiter. Dieses funktioniert für IPv4 und IPv6 problemlos. Für IPv4 kümmert er sich zusätzlich um gewisse Reservierungen und die Adressvergabe. Bei IPv6 (hierzu ist im RA das Flag „other config“ gesetzt) holt er sich Dinge wie DNS, Timeserver, Searchdomains usw… Wir wollen aus beschriebenen Gründen keine Adressreservierungen per DHCPv6. Ausgewählte Systeme bekommen hier eine eindeutige und vorher definierte IPv6 Adresse und der Rest darf alleine rechnen. DHCPv6 fällt also raus. Für diese Druckstation werden wir also ersteinmal die selbstgerechnete Adresse benutzen bis wir es zusammen mit unserem Servicepartner geschafft haben Samsung / HP davon zu überzeugen das es einen Bug in ihrem SyncThru Web Service gibt.

Wenn also jemand einen guten Kontakt hat….. Wir können ja nicht die Einzigen sein welche versuchen ein ULA Netz aufzubauen, oder?

Samsung / HP sind nicht die Einzigen welche hier noch Probleme haben. Wir sind noch auf viele andere spannende Dinge gestoßen und wir werden sich noch auf einige kommen. Ausgewählte wird es hier wie angekündigt geben!

TLS 1.3 ist da!

Im August wurde TLS 1.3 auf der IETFE-Tagung als fertig beschlossen 😀 Damit haben sich aber alle wirklich Zeit gelassen! OpenSSL hat am 11.09.2018 die Version 1.1.1 (LTS) freigegeben. Am 12.09.2018 ist diese in die FreeBSD Ports gekommen und:

root@www:/ # /usr/local/bin/openssl version
OpenSSL 1.1.1 11 Sep 2018

Fehlt also nur noch ein Eintrag in der make.conf und schon lässt sich nginx sauber dagegen bauen und alles automatisch mit portmaster auf dem neusten Stand halten 🙂

/etc/make.conf
DEFAULT_VERSIONS+= ssl=openssl111

Schaut mal nach, die meisten machen wohl jetzt schon TLS 1.3 beim lesen dieser Zeilen ^^

Qualys und SSL Labs hängen leider noch etwas nach, hier wird noch auf/gegen die Draft Version geprüft (For TLS 1.3 tests, we currently support draft version 28.). Aber ich wette das wird nicht mehr lange dauern!

Kleines Update, die HIGH-TECH Bridge Jungs testen sauber auf TLS 1.3.

Ich wurde gerade drauf hingewiesen, dass die Developer Version von ssllabs TLS 1.3 schon sauber testet. Danke Jost 😀

https://dev.ssllabs.com/ssltest/analyze.html?d=www.kernel%2derror.de&s=2a01%3a4f8%3a161%3a3ec%3a0%3a0%3a0%3a443&hideResults=on&latest

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑