Uno dei test che si fa rara­mente è quello di simu­lare il com­por­ta­mento di un sito o dell’attività di rete sulla WAN, in modo da avere un’idea suf­fi­cien­te­mente pre­cisa di come giri con una con­nes­sione in edge, ad esempio.

In realtà, la cosa non è dif­fi­cile se si è dispo­sti a spor­carsi le mani con il firewall. Per i pigri come me, però, c’è speed­li­mit: un pan­nello delle pre­fe­renze con cui impo­stare i para­me­tri che ci ser­vono, ovvero, per quali porte e per quali host limi­tare la banda ad un certo valore appli­cando anche un ritardo sulla comu­ni­ca­zione a piacere.

Attraverso @rentzsch ho sco­perto Localghost, un pro­gram­mino per con­fi­gu­rare al volo /etc/hosts, per defi­nire quali domi­nii pun­tano al 127.0.0.1

Basta lan­ciarlo, defi­nire le voci DNS e il gioco è fatto. Una volta create, le voci pos­sono essere atti­vate e disat­ti­vate a piacimento.

Qualche tempo fa ho sco­perto name­bench, una uti­lity per tro­vare il ser­ver DNS più per­for­mante nella zona in cui siamo in quel momento.

Il suo uso è molto sem­plice, basta lo screenshot:

Quello che all’inizio mi ha sor­preso, però, è vedere il DNS sulla LAN bat­tuto rego­lar­mente da quelli esterni. Credo che il motivo sia dovuto sem­pli­ce­mente a que­stioni di caching: è più pro­ba­bile che i nomi da risol­vere siano già in cache sui ser­ver esterni che su quello interno.

Infatti, se ripe­tiamo i test il diva­rio fra il DNS interno e quello esterno ten­dono a dimi­nuire. Usando come domini da risol­vere quelli nella cache di Safari, otteniamo:

1. 179% più veloce;
2. 90% più veloce;
3. 73%.

Il DNS interno rimane sì il più veloce in ter­mini asso­luti, con ~2ms di miglior rispo­sta con­tro ~ 26ms del DNS esterno migliore ma dall’altra parte il tempo peg­giore di rispo­sta è di ~1,5s per l’interno e ~0,5 per l’esterno, con una distri­bu­zione delle rispo­ste net­ta­mente a favore del ser­ver esterno.

Un DNS interno può rima­nere indi­spen­sa­bile per risol­vere i nomi sulla LAN ma il suo bene­fi­cio come cache può essere impor­tante di quanto si pensi.

Mac OS X Hints mi rin­fre­sca la memo­ria su come tro­vare l’indirizzo ip del ser­ver DHCP e mi “ispira” a pro­porre una ver­sione alter­na­tiva e più grezza. La solu­zione del post è un AppleScript men­tre quello che segue è un sem­plice wrap­per intorno a ipconfig(8).

 

#! /usr/bin/env tclsh 

foreach if [split [exec ifconfig -lu]] {
    if {[catch {
        exec ipconfig getoption $if server_identifier
    } result]} {
    } else {
 puts "$if: $result"
    }
}

 

Dal sem­pre utile Mac OS X hints ecco le istru­zioni per limi­tare l’uso della banda di alcune porte ip.

Nel caso non l’aveste sen­tito, Apple ha pre­sen­tato fra le altre cose un nuovo por­ta­tile, il MacBook Air ed è abba­stanza pro­ba­bile che ne abbiate già le tasche piene dei com­menti pro e con­tro, per cui aggiungo solo un paio di info che credo siano interessanti.

La prima riguarda la bat­te­ria che, secondo la docu­men­ta­zione, non è sosti­tui­bile dall’utente finale. Detto che è ovvia­mente meglio potersi cam­biare la bat­te­ria da soli, i pareri al riguardo sono discor­danti ma in ogni caso la que­stione è pro­ba­bil­mente irri­le­vante: secondo AppleInsider la sosti­tu­zione è comun­que banale.

La seconda noti­zia, più suc­cosa tec­no­lo­gi­ca­mente, riguarda la que­stione del (man­cante) let­tore ottico. Apple, per ovviare a que­sta man­canza, for­ni­sce un pro­gramma chia­mato Remote Disc per l’installazione via rete. Rete?  Ma il MacBook Air non ha nem­meno la porta Ethernet!

Questo vuol che Remote Disc è capace di fare da ser­ver NetBoot e che il MacBook Air può fare il boot via wire­less, cosa che Apple stessa scon­si­gliava fino a ieri. La que­stione non è di poco conto sia per l’entità delle modi­fi­che pre­su­mi­bil­mente richie­ste all’EFI e alla solu­zione di “det­ta­gli” come l’accesso a WLAN crip­tate, ad esempio.

Come spesso accade, la pro­po­sta di Apple non fa molti com­pro­messi: “love it or leave it”. La mia opi­nione? Non è la mia mac­china ideale, non ora… E voi, siete tentati?

Questo arti­colo di Apple sul firewall di Leopard con­tiene alcuni det­ta­gli inte­res­santi. Il primo – e più noto – è che si tratta di un firewall che lavora a livello di appli­ca­zione e non a livello di porte: mi basta dire che deve accet­tare le con­nes­sioni entranti per iTu­nes, invece che dover spe­ci­fi­care quali siano le porte usate dall’applicazione, ad esempio.

Ma più oltre si tro­vano pre­ci­sa­zioni da tenere a mente. Sul “livello” a cui lavora que­sto software:

The Application Firewall does not over­rule rules set with ipfw, because ipfw ope­ra­tes on pac­kets at a lower level in the net­wor­king stack.

Riguardo ai legami fra il firewall e il code signing:

When you add an appli­ca­tion to this list, Mac OS X digi­tally signs the appli­ca­tion (if it has not been signed already). If the appli­ca­tion is modi­fied, you will be promp­ted to allow or deny inco­ming net­work con­nec­tions to it. Most appli­ca­tions do not modify them­sel­ves, and this is a safety fea­ture that noti­fies you of the change.

Quindi il code signing può avve­nire anche ex post, per una sin­gola appli­ca­zione, men­tre pen­savo fosse una pre–condizione da sod­di­sfare prima di appli­care delle regole con il firewall. Tant’è vero che più sotto si pre­cisa che se un’applicazione non pre­sente nell’elenco cerca di effet­tuare un qual­che tipo di con­nes­sione, viene pre­sen­tata una fine­stra di dia­logo che chiede all’utente cosa fare e, nel caso in cui, accon­senta all’esecuzione dell’applicazione, quest’ultima viene firmata.

Infine, se non espli­ci­ta­mente aggiunte come appli­ca­zioni escluse, tutti i pro­cessi che girano come root o sono fir­mate da una Certificate Authority fidata (come quelle di Apple) hanno pos­si­bi­lità di effet­tuare connessioni.

Come molti di voi sapranno, ieri è uscito Mac OS X 10.5 e una delle cose che mi incu­rio­si­vano di più era capire il fun­zio­na­mento della fea­ture chia­mata “Back to My Mac”, ovvero, la pos­si­bi­lità di acce­dere ad un pro­prio com­pu­ter regi­strato su .Mac da un’altra mac­china via inter­net, anche se il com­pu­ter sta in un rete locale die­tro un NAT.

Perché que­sta cosa fun­zioni è neces­sa­rio che il rou­ter della pro­pria rete locale sup­porti uno di que­sti due pro­to­colli: il NAT-PMP o l’UPnP. Il primo è sicu­ra­mente sup­por­tato dagli ultimi modelli di Airport, l’altro – UPnP – è più pro­ba­bil­mente atti­va­bile sugli altri router.

Per altre info:

• Using Back to My Mac in Mac OS X 10.5 Leopard;
• Mac OS X 10.5: Back to My Mac requi­res AirPort base sta­tion or UPnP-capable third-party rou­ter;
• Back to My Mac: Supported rou­ter devi­ces (Mac OS X 10.5 Leopard).