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 è www.microsoft.com. Infatti, effettuando una richiesta appositamente forgiata mediante il tool hping3, è possibile identificare l’IP ID, grazie al quale si può capire se le risposte provegnono da una sola macchina o da più macchine dietro bilanciamento:
nightfly@nightbox:~$ sudo hping3 www.microsoft.com -S -p 80 HPING www.microsoft.com (eth0 65.55.57.27): S set, 40 headers + 0 data bytes len=46 ip=65.55.57.27 ttl=245 DF id=19756 sport=80 flags=SA seq=0 win=8190 rtt=221.3 ms len=46 ip=65.55.57.27 ttl=245 DF id=3683 sport=80 flags=SA seq=1 win=8190 rtt=219.9 ms len=46 ip=65.55.57.27 ttl=245 DF id=65490 sport=80 flags=SA seq=2 win=8190 rtt=228.5 ms len=46 ip=65.55.57.27 ttl=245 DF id=46898 sport=80 flags=SA seq=3 win=8190 rtt=227.8 ms len=46 ip=65.55.57.27 ttl=245 DF id=63574 sport=80 flags=SA seq=4 win=8190 rtt=227.6 ms
Poichè il campo id varia di richiesta in richiesta e non è strettamente incrementale (dato che il suo scopo reale è quello di identificare i vari pacchetti IP frammentati, consentendo al destinatario di ricostruire le informazioni originarie nel giusto ordine), abbiamo dimostrato che effettivamente www.microsoft.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.