Qualche tempo fa un mio collaboratore mi ha segnalato uno strano problema sulla rete. Egli lamentava che un certo gruppo di utenti (chiamiamolo X per semplicità), non riusciva ad accedere ad un determinato sito Web (Connection Timeout), mentre un altro gruppo di utenti (Y), ci accedeva tranquillamente.
Ovviamente, entrambi i gruppi di utenti (X e Y) appartenevano alla stessa VLAN, ergo afferivano alla medesima policy di load balancing e quindi si presentavano all'esterno utilizzando lo stesso modem (ISP e IP pubblico).
Ora, lasciando perdere alcune impostazioni del firewall interno (ad esempio il conntrack), che avrebbero potuto inficiare le sessioni Web dirette al sito target, l'unica spiegazione plausibile riguardava un qualche tipo di problema sul sito consultato dagli utenti.
Prima possibile causa: il sito target si trova dietro un load balancer, il quale si occupa di smistare le richieste di connessione ai frontend in base a determinate policy predefinite.
Un esempio di sito Web dietro load balancer è facebook.com. Infatti, effettuando una richiesta mediante wget della pagina www.facebook.com si ottiene il seguente output:
nightfly@nightbox:~$ wget www.facebook.com
--2013-08-14 13:52:21-- http://www.facebook.com/
Risoluzione di facebook.com (www.facebook.com)... 31.13.86.16, 2a03:2880:2050:3f07:face:b00c:0:1
Connessione a facebook.com (www.facebook.com)|31.13.86.16|:80... connesso.
e dopo qualche minuto (ovvero il tempo necessario per far scadere la sessione sul load balancer di destinazione), lanciando nuovamente il suddetto comando avremo:
nightfly@nightbox:~$ wget www.facebook.com
--2013-08-14 14:28:18-- http://www.facebook.com/
Risoluzione di www.facebook.com (www.facebook.com)... 31.13.64.1, 2a03:2880:10:6f08:face:b00c:0:1
Questo dimostra che effettivamente facebook.com utilizza i load balancer (e non potrebbe essere altrimenti dato il grande numero di hits giornaliere che lo coinvolgono).
Per quanto riguarda il DNS Round Robin un metodo per identificare i domini che lo implementano consiste nell'uso di dig. Ad esempio, per google.com avremo:
nightfly@nightbox:~$ dig google.com NS
; <<>> DiG 9.8.1-P1 <<>> google.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13716
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN NS
;; ANSWER SECTION:
google.com. 172098 IN NS ns4.google.com.
google.com. 172098 IN NS ns3.google.com.
google.com. 172098 IN NS ns1.google.com.
google.com. 172098 IN NS ns2.google.com.
;; Query time: 138 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 14 13:58:47 2013
;; MSG SIZE rcvd: 100
ovvero ho interrogato il dominio google.com alla ricerca dei nameserver autoritativi. Adesso eseguo una ricerca più approfondita interrogando uno dei suddetti nameserver:
nightfly@nightbox:~$ dig @ns1.google.com google.com
; <<>> DiG 9.8.1-P1 <<>> @ns1.google.com google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18692
;; flags: qr aa rd; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 173.194.35.40
google.com. 300 IN A 173.194.35.33
google.com. 300 IN A 173.194.35.37
google.com. 300 IN A 173.194.35.46
google.com. 300 IN A 173.194.35.38
google.com. 300 IN A 173.194.35.39
google.com. 300 IN A 173.194.35.34
google.com. 300 IN A 173.194.35.35
google.com. 300 IN A 173.194.35.32
google.com. 300 IN A 173.194.35.41
google.com. 300 IN A 173.194.35.36
;; Query time: 103 msec
;; SERVER: 216.239.32.10#53(216.239.32.10)
;; WHEN: Wed Aug 14 14:00:05 2013
;; MSG SIZE rcvd: 204
Dal numero piuttosto consistente di record A DNS si evince che google.com attua la politica di DNS Round Robin. Come ulteriore conferma proviamo a pingare il dominio in questione:
nightfly@nightbox:~$ ping google.com
PING google.com (173.194.40.8) 56(84) bytes of data.
64 bytes from mil02s06-in-f8.1e100.net (173.194.40.8): icmp_req=1 ttl=55 time=46.4 ms
64 bytes from mil02s06-in-f8.1e100.net (173.194.40.8): icmp_req=2 ttl=55 time=62.5 ms
e successivamente eseguendo un altro ping in rapida successione otterremo:
nightfly@nightbox:~$ ping google.com
PING google.com (173.194.40.7) 56(84) bytes of data.
64 bytes from mil02s06-in-f7.1e100.net (173.194.40.7): icmp_req=1 ttl=55 time=51.0 ms
64 bytes from mil02s06-in-f7.1e100.net (173.194.40.7): icmp_req=2 ttl=55 time=90.6 ms
Si evince, molto banalmente, che i pingando google.com hanno risposto due indirizzi IP pubblici differenti (
173.194.40.8 e 173.194.40.7).
Per diritto di cronaca, il problema che ha riguardato gli utenti della LAN era dovuto ad un'errata configurazione del load balancer del sito target, il quale, seguendo una politica di Round Robin, a volte girava le connessioni ad un frontend "troppo carico", il quale le droppava brutalmente.
Alla prossima.