A10 – GSLB : Déploiement d’un serveur DNS intelligent
Introduction
Cet article présente en détail le mode « serveur DNS » de l’A10 avec sa fonctionnalité Global Server Load Balancing (GSLB) afin de garantir la disponibilité de services Web.
L’idée étant de déléguer la gestion complète d’un sous-domaine public à l’A10. Ainsi, en fonction de la disponibilité des services Web ou des liens Internet, il sera en mesure d’adapter sa réponse DNS.
Nous verrons un exemple de configuration type d’un cluster A10 qu’il est possible d’utiliser pour un centre de données avec deux liens Internet, les prérequis pour sa mise en œuvre, et des schémas explicatifs.
Nous étudierons que la partie DNS dans cet article, il n’y aura donc pas de détail pour la partie firewall.
Bonne lecture.
Prérequis
Il est nécessaire d’avoir accès au panneau de configuration de son fournisseur DNS public (MyDNS dans notre exemple), et bien sûr à minima un accès administrateur sur un A10 (fichier de configuration à adapter si une seule unité).
Chacun des A10 devra être placé entre les routeurs de vos fournisseurs d’accès Internet et vos firewalls. Ils devront donc tous être placés dans le même VLAN (un VLAN dédié de préférence par FAI, pour éviter tout conflit de niveau 2). L’A10 exposera le port DNS (UDP uniquement) directement sur Internet.
Contrainte : gardez en tête que chacun des A10 (dans le cas d’un cluster de deux unités) devra avoir ses propres adresses IP publiques pour fonctionner (le masque de sous-réseau de chacun des liens FAI doit être suffisamment large pour un adressage IPv4). Voir l’exemple de configuration plus bas pour mieux comprendre.
Données fictives de notre exemple
Pour notre exemple, nous utiliserons les données suivantes :
- Le fournisseur MyDNS est le serveur faisant autorité pour le domaine public « mydomain.com«
- Le sous-domaine délégué au cluster A10 est « gslb.mydomain.com«
- Deux FAI avec les sous-réseaux suivants :
- myisp1 : 1.2.3.0/28, passerelle/routeur FAI = 1.2.3.14
- myisp2 : 2.3.4.0/28, passerelle/routeur FAI = 2.3.4.14
- Le nom public de notre service Web (FQDN) que l’on héberge : « mysite.mydomain.com«
Requête DNS récursive
Voici un schéma ci-dessous pour mieux comprendre le cheminement complet d’un première requête DNS depuis le poste d’un utilisateur (navigateur) avec l’intervention d’un A10 pour l’accès au service Web :
Nous voyons qu’à l’étape 5 le serveur MyDNS va répondra avec une redirection CNAME afin que le serveur local DNS puisse interroger l’A10.
Suivant nos critères de disponibilités et l’état du « health check », l’A10 répondra avec l’adresse IPv4 adéquate à l’étape 7, toujours au serveur local DNS.
Configuration DNS « MyDNS »
Différents changements sont à faire sur votre serveur DNS public, voici les ajouts à apporter :
- NS records :
- gslb.mydomain.com = vdns1.mydomain.com
- gslb.mydomain.com = vdns2.mydomain.com
- A records (glue) :
- vdns1.mydomain.com = 1.2.3.10
- vdns2.mydomain.com = 2.3.4.10
- CNAME records :
- mysite.mydomain.com = mysite.gslb.mydomain.com
On déclare deux serveurs DNS « virtuels » avec leur adresse IPv4 respective ainsi que le fameux CNAME correspondant à notre service Web que l’on souhaite atteindre.
Configuration A10
Voici le fichier de configuration complet avec les explications au-dessous (fichier propre en téléchargement juste au-dessous) :
! On utilise une partition A10 dédiée pour les requêtes DNS publiques
active-partition dns
!
! Les interfaces 1/* correspondent à l'unité A10 primaire
interface ethernet 1/3
name myisp1
enable
ip address 1.2.3.2 255.255.255.240
!
interface ethernet 1/4
name myisp2
enable
ip address 2.3.4.2 255.255.255.240
! Les interfaces 2/* correspondent à l'unité A10 secondaire (secours)
interface ethernet 2/3
name myisp1
enable
ip address 1.2.3.3 255.255.255.240
!
interface ethernet 2/4
name myisp2
enable
ip address 2.3.4.3 255.255.255.240
!
! Routage (/ défaut) de l'unité A10 primaire, FAI myisp1 est préféré
device-context 1
ip route 0.0.0.0 /0 1.2.3.14
ip route 0.0.0.0 /0 2.3.4.14 100
! Routage (/ défaut) de l'unité A10 secondaire (secours), FAI myisp1 est préféré
device-context 2
ip route 0.0.0.0 /0 1.2.3.14
ip route 0.0.0.0 /0 2.3.4.14 100
! Serveur DNS public (Cloudflare et APNIC) utilisé pour valider l'accès Internet
health monitor ping-one
override-ipv4 1.1.1.1
! Serveur virtuel DNS FAI myisp1, port d'écoute, GSLB et réponse par le même lien
slb virtual-server dns1-myisp1 1.2.3.10
port 53 dns-udp
gslb-enable
use-rcv-hop-for-resp
! Serveur virtuel DNS FAI myisp2, port d'écoute, GSLB et réponse par le même lien
slb virtual-server dns2-myisp2 2.3.4.10
port 53 dns-udp
gslb-enable
use-rcv-hop-for-resp
! Configuration adresse IPv4 du service Web "mysite.gslb.mydomain.com" sur myisp1
gslb service-ip myisp1-5 1.2.3.5
health-check ping-one
port 443 tcp
! Configuration adresse IPv4 du service Web "mysite.gslb.mydomain.com" sur myisp2
gslb service-ip myisp2-5 2.3.4.5
health-check ping-one
port 443 tcp
! Configuration de notre premier site = FAI myisp1
gslb site myisp1
ip-server myisp1-5
! Configuration de notre second site = FAI myisp2
gslb site myisp2
ip-server myisp2-5
! Notre politique (un seul lien actif/utilisé, priorités, préférences etc...)
gslb policy gslb-policy
health-check-preference-enable
weighted-ip-enable
no geographic
no round-robin
metric-force-check
metric-fail-break
metric-order health-check weighted-ip
dns backup-server
dns selected-only 1
dns logging both
dns server authoritative
! Zone où l'on gère notre sous-domaine, déclaration des différents A records
gslb zone gslb.mydomain.com
policy gslb-policy
dns-ns-record vdns1.mydomain.com
dns-ns-record vdns2.mydomain.com
service 443 mysite
dns-a-record myisp1-5 ttl 60 static
dns-a-record myisp2-5 as-backup ttl 60 static
!
end
Avec cette configuration, l’A10 sera d’un côté en mesure de vérifier que l’accès Internet fonctionne par les deux liens FAI (en passant par leurs routeurs, test ICMP des routeurs et DNS 1.1.1.1), et de l’autre que vos services Web sont accessibles par les firewalls (test ICMP + port(s) accessible(s)).
Je fais en sorte que toutes les requêtes DNS (et tests) empruntent le même chemin à l’aller et au retour (important).
Dans la mesure du possible, tous les services Web répondront par le même lien Internet / même FAI (mode actif/passif).
Dépendance de services Web
Dans le cas de l’hébergement d’une application Web qui utiliserait/exposerait plusieurs services Web (plusieurs ports réseaux), il est parfois nécessaire voire obligatoire de tous les conserver sur le même lien Internet (même FAI). Il suffit d’ajouter ceci dans le fichier de configuration :
!
gslb service-group SG-App-Web
member app1.gslb.mydomain.com
member app2.gslb.mydomain.com
member app3.gslb.mydomain.com
dependency site
!
Ainsi, si l’un des 3 services Web ne fonctionne plus par le lien primaire, on bascule tous les services sur le lien secondaire. Les réponses DNS proviendront toujours par/pour le même lien Internet/FAI.
Debug et vérifications
Quelques commandes utiles (console) pour faire un debug et visualiser les requêtes DNS en live.
Ici on paramètre le debug sur les paquets UDP et port 53 :
debug packet l4-protocol udp 53
debug gslb
show debug
On active notre debug :
debug monitor
Sur une autre station (Linux) cliente (adresse IPv4 publique 11.22.33.44) on lance une requête DNS (dig) :
dig @1.1.1.1 mysite.mydomain.com +short
Côté client on aura une réponse du type :
mysite.gslb.mydomain.com.
1.2.3.5
Et côté serveur/A10 :
@2686679073 i( 3, 1)> ip 11.22.33.44 > 1.2.3.10 udp 43888 > 53 len 66 qry id 139
mysite.gslb.mydomain.com:443 [179111:56 - Query:received], 11.22.33.44 -> 1.2.3.10, Policy: gslb-policy, Records: 2
rcode: 0[Success]
mysite.gslb.mydomain.com:443 [179111:56 - Metric:Start], Policy: gslb-policy, Last Hit: mysite-myisp1:1.2.3.5, Last Hit of Zone: mysite-myisp1:1.2.3.5
Preferred Records
IN A 1.2.3.5
IN A 2.3.4.5
mysite.gslb.mydomain.com:443 [179111:56 - Metric:health check]
Preferred Records
IN A 1.2.3.5, State: Port UP preference 0
IN A 2.3.4.5, State: Port UP preference 0
mysite.gslb.mydomain.com:443 [179111:56 - Metric:weighted IP]
Preferred Records
IN A 1.2.3.5, Weight: None
IN A 2.3.4.5, Weight: None
mysite.gslb.mydomain.com:443 [179111:56 - Response:sent]
@2686679073 o( 3, 0)> ip 1.2.3.10 > 11.22.33.44 udp 53 > 43888 len 111 qry id 139
Ce site est également très utile pour vérifier en quasi temps réel la résolution DNS d’un site Web sur la planète :
Conclusion
C’est un déploiement de base de GSLB et d’un serveur DNS mais qui reste fonctionnel et fiable.
Nous pourrions aller plus loin en utilisant d’autres critères GLSB, dans le cas d’un balancement géographique par exemple, avec un second centre données. Nous verrons cela plus tard dans un autre article.
En attendant, j’espère que cela pourra rendre services à certains et donner des pistes.
Dernier point, il est toujours bon de lancer un scan externe sur les adresses IP publiques utilisées pour s’assurer qu’aucun port n’est exposé involontairement en dehors de UDP 53 :
https://github.com/choupit0/MassVulScan
N’hésitez pas si un point n’est pas clair.