igwan.net

Aller au contenu | Aller au menu | Aller à la recherche

dimanche 25 novembre 2018

Technique : économiser les IPv4 sur un LAN avec DHCP sur EdgeOS

Il vous reste des IPv4 publiques et vous voulez les attribuer directement à vos utilisateurs à travers DHCP en attendant de tout passer en pur IPv6 ?

Problème : si vous affectez par exemple un /28 sur un LAN (16 adresses), 3 de ces adresses deviennent inutilisables pour vos utilisateurs (la première, la dernière, et la passerelle). Ce qui fait pas loin de 20% d'adresses perdues.

Pour utiliser pleinement nos 16 adresses, nous allons mettre à profit les options DHCP. Voici comment faire sur un routeur Ubiquiti.

Dans cet exemple :

  • eth3 est l'interface sur laquelle nos utilisateurs se connectent
  • 203.0.113.16/28 est le sous-réseau d'IP publiques que l'on souhaite attribuer à nos utilisateurs (de 203.0.113.16 à 203.0.113.31)
  • 169.254.0.3/32 est l'adresse privée (link-local) que l'on choisi d'utiliser comme passerelle sur notre interface

Petite subtilité, l'adresse 169.254.0.3 devra être convertie au format hexadécimal pour être utilisée dans les options DHCP. Ici 169.254.0.3 converti en hexadécimal devient a9:fe:00:03

## on configure une adresse qui va servir de passerelle à nos utilisateurs
set interfaces ethernet eth3 address 169.254.0.3/32

## on indique à notre routeur que les IP publiques sont joignables sur l'interface eth3
set protocols static interface-route 203.0.113.16/28 next-hop-interface eth3

## on prépare le serveur DHCP à reconnaitre nos options
set service dhcp-server global-parameters 'option rfc3442-static-route code 121 = string;'
set service dhcp-server global-parameters 'option windows-static-route code 249 = string;'

## on configure le serveur DHCP
set service dhcp-server shared-network-name PUBLICWIFIETH3 authoritative enable

# on référence l'adresse configurée sur eth3 pour que le démon DHCP puisse correctement associer notre configuration à la bonne interface
set service dhcp-server shared-network-name PUBLICWIFIETH3 subnet 169.254.0.3/32 lease 3600

# on configure DHCP pour notre sous-réseau d'IPv4 publiques
set service dhcp-server shared-network-name PUBLICWIFIETH3 subnet 203.0.113.16/28 lease 3600
set service dhcp-server shared-network-name PUBLICWIFIETH3 subnet 203.0.113.16/28 start 203.0.113.16 stop 203.0.113.31
set service dhcp-server shared-network-name PUBLICWIFIETH3 subnet 203.0.113.16/28 subnet-parameters 'option subnet-mask 255.255.255.255;'
set service dhcp-server shared-network-name PUBLICWIFIETH3 subnet 203.0.113.16/28 default-router 169.254.0.3
set service dhcp-server shared-network-name PUBLICWIFIETH3 subnet 203.0.113.16/28 dns-server 192.0.2.53

# enfin on ajoute les options qui seront envoyées au client DHCP pour indiquer que 169.254.0.3 (la passerelle) se trouve sur l'interface.
# Attention à remplacer a9:fe:00:03 dans l'exemple par la conversion hexadécimale de l'adresse de votre propre passerelle
set service dhcp-server shared-network-name PUBLICWIFIETH3 subnet 203.0.113.16/28 subnet-parameters 'option rfc3442-static-route 20:a9:fe:00:03:00:00:00:00:00:a9:fe:00:03;'
set service dhcp-server shared-network-name PUBLICWIFIETH3 subnet 203.0.113.16/28 subnet-parameters 'option windows-static-route 20:a9:fe:00:03:00:00:00:00:00:a9:fe:00:03;'

Le premier client DHCP qui se connecte recevra la configuration suivante :

  • adresse: 203.0.113.16
  • masque de sous-réseau: 255.255.255.255
  • passerelle par défaut: 169.254.0.3

Il aura également une route statique lui permettant de joindre la passerelle.

samedi 29 septembre 2012

Technique : configuration d'un hotspot IPv6-only

Ce qui devrait marcher ...

L'approche naïve :

  • le routeur annonce en :
    • un subnet IPv6 /64
    • l'adresse d'un résolveur DNS classique
  • aucune configuration relative à l'IPv4, pas de DHCPv4, pas d'ARP

... ne marche pas encore

Malheureusement, certains OS ne sont pas prêts pour l'IPv6-only :

  • Ubuntu (12.04), Android, ... s'attendent à obtenir une adresse IPv4 avant de considérer qu'ils sont connectés
  • Windows 7 conserve une adresse IPv4 qu'il a obtenu lors d'une précédente connexion (y compris sur un autre point d'accès !) tant qu'il n'obtient pas de nouvelle. Il reste donc en mode "connectivité limitée" pendant un long moment.

Par ailleurs, même si les sites web les plus populaires ont sauté le pas (Google, Youtube, Facebook, ...), beaucoup n'ont pas encore activé l'IPv6 sur leurs serveurs.

Contourner sans abdiquer

Pour contourner ces problèmes, sans pour autant offrir de router de l'IPv4 natif, nous avons adopté l'approche suivante :

  • on annonce un résolveur DNS64, cela permet au moins aux sites web en IPv4 seul d'être accessibles
  • pour contenter les OS qui veulent absolument une réponse à leurs requêtes DHCPv4 :
    • on attribue une adresse au client dans une plage d'IPv4 "privée" RFC 1918
    • on fournit l'adresse IPv4 d'un proxy DNS local, lui même configuré pour faire suivre les requête sur le résolveur DNS64
    • mais ne fournit pas de route IPv4 par défaut ; ainsi pas de routage IPv4 possible

Prochainement

Déléguer des blocs IPv6 complets avec DHCP-PD (prefix delegation) aux routeurs qui en font la demande.