Ore 0:53, sono appena arrivato a casa dopo una serata passata nel datacenter del mio cliente invece di essere a cena con Greta.
Tutto e’ iniziato alle 20:15 con l’arrivo di una chiamata di un collega (Pj), che mi chiedeva se questa sera dopo le 21:00 avessi potuto lavorare con lui, all’analisi di un problema verificatosi in giornata su un’applicazione per video chiamata basata su protocollo SIP.
Ovviamente non potevo “esimermi” da tale impegno, dato che il tono di Pj lasciava trasparire che il problema “esigeva” una soluzione nel breve termine e che molto probabilmente anche questa volta il commerciale si era “prostituito” col cliente finale promettendo una soluzione in tempi rapidi…ssimi.
In breve:
il client dell’applicazione (installata presso il call center) deve collegarsi ad un server (in IDC) utilizzando il protocollo SIP con porta sorgente 5060 e porta di destinazione 5060, ma dai logs del firewall emerge che “qualcosa” modifica la porta sorgente del client, infatti tutti i frames vengono allegramente droppati dal firewall perche sorgenti da porte random (???????). Ovviamente tutti i vari carrier che forniscono servizi di rete nel “mezzo” (tra il call center e l’IDC) giurano di non apportare nessun tipo di modifica, quindi tocca a noi fare l’analisi.
Del resto questa è la professione che ho scelto, per cui parto alla volta dell’ IDC Settimo Milanese, faccio tappa in autogrill per pieno di gasolio (quando si ha fretta, il serbatoio e’ sempre vuoto) e sacchetto con panino e bibita, conscio del fatto che quella sarebbe stata la mia cena.
Arrivo all’IDC alle ore 21:15, preparo il portatile, ripassando mentalmente la topologia della rete realizzata piu di una anno fa e che nel frattempo ha subito notevoli modifiche (gli switch sono piu del doppio, rispetto a quelli installati in origine), apro un terminale sullo switch sul quale e’ attestata la rete MPLS che collega il call center all’IDC per configurare l’interfaccia in mirror e verificare se il traffico in ingresso è effettivamente quello che ci apettiamo di ottenere, verificando che nessuna delle parti coinvolte abbia commesso spergiuro.
Chiamo Pj e lo informo, intanto collego il pc, avvio lo sniffer per raccogliere il traffico di un paio di minuti, ed effettivamente le richieste dirette al server sono “pulite” (source 5060, destination 5060), nessuno ha commesso spergiuro, il problema è altrove.
Sempre al telefono col “serafico” Pj, apro un terminale sul nodo attivo del firewall (cluster Checkpoint), avvio tcpdump sull’interfaccia in ingresso del firewall, ma anche qui il traffico in ingresso è pulito, avvio tcpdump sull’interfaccia in uscita e BANG…trovato!!!!
Dal firewall le richieste entrano corrette, ma escono modificate, la porta sorgente non e’ piu’ 5060 ma e’ 14322 (?????), vuol dire che il software di firewalling apporta alcune modifiche, Pj si abbandona ad un sarcastico “ottimo”.
Apro la rule based, verifico la regola, ma è corretta (source x.x.x.x, destination y.y.y.y, service “sip”), domani dovremo contattare l’assistenza e aspettare che rispondano in “tempi biblici”, Pj non e’ felice di doverlo dire al cliente.
Nel frattempo che Pj informa il tecnico che si occupa dell’applicazione in questione, apro le proprieta’ dell’oggetto “sip” di checkpoint e noto che è attivo il “packet inspection”, in pratica checkpoint non si limita a controllare IP e porta, ma verifica se il protocollo in transito sia effettivamente SIP.
Vado su google, cerco un possibile caso analogo, e trovo il post di uno sventurato che si e’ scontrato con un problema analogo utilizzando ASTERISK, il quale suggerisce, per risolvere il problema, di impostare il packet inspection a “none”.
Lo faccio, chiedo a Pj di ripetere la prova, acconsente….FUNZIONA!!!!!!!!!.
Ci siamo salutati contenti di aver trovato la soluzione, seppur un po’ amareggiati per aver capito che checkpoint ne era la causa.