Sul mio Mac l'interfaccia ipsec0
ha un indirizzo IPv6 che fa parte di /64
:
2607: fb90: 13c0: e82 :: / 64 che è di proprietà di T-Mobile come visto dal whois:
CIDR: 2607:FB90::/32
NetName: TMOV6-1
NetHandle: NET6-2607-FB90-1
Parent: NET6-2600 (NET6-2600-1)
NetType: Direct Allocation
OriginAS: AS21928
Organization: T-Mobile USA, Inc. (TMOBI)
RegDate: 2009-07-14
Updated: 2012-02-24
Ref: http://whois.arin.net/rest/net/NET6-2607-FB90-1
Poiché si tratta di un tunnel ipsec, possiamo scoprire quale sia l'indirizzo dell'endpoint cercando il traffico sulla nostra interfaccia principale in uscita (tcpdump su en0
per esempio), che è dove scopriamo che 208.54.40.75
è l'endpoint indirizzo, che possiamo ancora whois e tornare:
NetRange: 208.54.0.0 - 208.54.159.255
CIDR: 208.54.128.0/19, 208.54.0.0/17
NetName: TMO2
NetHandle: NET-208-54-0-0-1
Parent: NET208 (NET-208-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: T-Mobile USA, Inc. (TMOBI)
RegDate: 1999-08-10
Updated: 2012-02-24
Ref: http://whois.arin.net/rest/net/NET-208-54-0-0-1
Quindi ora la parte interessante, che cosa sta aprendo questa connessione e a cosa serve?
Un pratico comando per questo è denominato lsof
che elenca i file aperti. Possiamo passarlo un paio di flag e tornare indietro a ciò che sta ascoltando, insieme al processo in ascolto.
lsof -a -i -l -P | grep 2607:fb90:13c0:e82
A quel punto vediamo qualcosa di simile al seguente:
ntpd 198 0 32u IPv6 0x1c220855d5c2b5a1 0t0 UDP [2607:fb90:13c0:e82::]:123
CommCente 249 1001 26u IPv6 0x1c220855d59e9a91 0t0 UDP [2607:fb90:13c0:e82::]:5060
CommCente 249 1001 27u IPv6 0x1c220855d3b35a61 0t0 TCP [2607:fb90:13c0:e82::]:5060 (LISTEN)
Il secondo numero elencato è il PID (ID processo) per il processo che ha la connessione aperta, in modo da ottenere maggiori dettagli su quali altre connessioni sono aperte utilizzando:
lsof -a -i -l -P -p 249
Questo produrrà qualcosa di simile al seguente:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
CommCente 249 1001 15u IPv4 0x1c220855d68c85a1 0t0 UDP 10.64.1.100:500->m4b2836d0.tmodns.net:500
CommCente 249 1001 20u IPv4 0x1c220855d336be89 0t0 UDP 10.64.1.100:4500->m4b2836d0.tmodns.net:4500
CommCente 249 1001 26u IPv6 0x1c220855d59e9a91 0t0 UDP [2607:fb90:13c0:e82::]:5060
CommCente 249 1001 27u IPv6 0x1c220855d3b35a61 0t0 TCP [2607:fb90:13c0:e82::]:5060 (LISTEN)
Possiamo vedere che questo ha una connessione aperta sulla porta 500 e 4500. La porta 500 viene utilizzata per lo scambio di chiavi quando si utilizza una VPN basata su IPSec e 4500 viene usato per i tunnel IPSec per attraversare NAT, vedere questa pagina per maggiori informazioni: link
E poi le informazioni sul processo stesso:
ps auxwww | grep 249:
xistence 249 0.0 0.2 2582352 29932 ?? S 2:07PM 0:03.34 /System/Library/Frameworks/CoreTelephony.framework/Support/CommCenter
Quindi basandoci su questo possiamo fare un paio di assunzioni:
- Gli endpoint del tunnel sono di proprietà di T-Mobile
- Deve fare qualcosa con CoreTelephony che sembra essere una libreria utilizzata da Apple per implementare le chiamate telefoniche su iOS (e ora su OS X): link
- Basato su 1 e 2, e sapendo che ho abilitato la funzione di chiamata Wifi in FaceTime e sul mio telefono, posso essere abbastanza certo che questo tunnel ipsec viene utilizzato per instradare le chiamate al mio laptop.
Non appena avvio una chiamata FaceTime Wifi mentre eseguo tcpdump
nell'interfaccia ipsec0
, vedo lo standard SIP protocollo (che è quello che FaceTime usa per effettuare chiamate).
tl; dr: ipsec0
è usato per le chiamate Wifi.