Archives de la mois: janvier 2024

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 :

https://dnschecker.org/

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.