Il presente articolo è stato tradotto automaticamente.

Giochi

Introduzione a IPsec VPN nei telefoni cellulari

Ramon Arjona

Questo pomeriggio, mentre era lontani dall'ufficio, viene visualizzato un messaggio di posta elettronica al telefono. È stato un collegamento a un documento che doveva per leggere--un documento in un sito di SharePoint disponibile solo tramite l'intranet il messaggio. Questo era un bummer causa l'attendere fino a quando Impossibile avviare il computer portatile, inserire la smart card nel lettore di smart card, ottenere una connessione Wi-Fi un bar, connettersi mio computer portatile aziendale VPN e accedere prima è impossibile leggere il documento.

Vita sarebbe molto più semplice se semplicemente Impossibile usare il telefono per accedere al sito SharePoint. Naturalmente, il telefono sarebbe necessario qualche modo magic di connessione in modo protetto alla rete aziendale e l'autenticazione utente. In altre parole, come il mio computer portatile, il telefono necessario la possibilità di avviare una connessione VPN alla rete. Sono disponibili molti modelli di telefono commerciale, inclusi telefoni Windows, un client VPN incorporato. Ma esistono alcuni difetti in più ampiamente disponibili client VPN poiché essi si basano sulla versione 1 di una specifica di Internet Key Exchange (IKEv1). IKEv1 costituisce una parte stabile del framework IPsec ed è ideale per reti cablate dispositivi o dispositivi, quali computer portatili, con batterie di dimensioni relativamente grandi che non è possibile spostare intorno a una quantità eccessiva. Tuttavia, non è ideale per telefoni cellulari.

Utilizzo, una connessione senza fili sul mio computer portatile per passare da mio ufficio a una sala conferenze e viceversa. È possibile passare da una connessione wireless a una cablata e prevede che alcuna perdita di connettività. Ma è non spostarsi quasi quanto con un computer portatile come facciamo con un telefono. Un telefono viaggia con l'utente attraverso il traffico e in e da edifici, transizione in ingresso e in uscita lo stato comune. A meno che non si utilizzi un modem cellulare, quando è stata l'ultima volta che il computer portatile detto che è stato comune? In genere, un telefono modifica il punto di collegamento di rete con una frequenza e la complessità che un computer portatile non deve preoccuparsi. Il guys che pensato IKEv1 specifica non è necessario sugli scenari di telefono cellulare, poiché non sono in anni ' 90 tardiva, veniva scritto quando RFC 2409, telefoni intelligenti appena sono prevalenti nel mercato. Da allora, ha skyrocketed l'utilizzo di telefoni cellulari e ha iniziato l'importanza del telefono cellulare affrontare l'importanza di altri, più grande dispositivi di elaborazione, come la workstation o il computer portatile.

IKEv1 non è adatto a uno stile ad alta mobilità di elaborazione perché IKEv1 non dispone di un buon metodo per far fronte a un host che potrebbe modificare il punto di rete allegato several times a few espresso in secondi. Quando è stata scritta IKEv2, un insieme di estensioni il PC portatile e multihoming (MOBIKE) il protocollo è stata scritta anche per supportare lo scenario del telefono cellulare. Telefono cellulare 2009a VPN utilizza le estensioni, diventa molto più pratico. Diversi prodotti sul mercato supportano IKEv2 e MOBIKE, tra cui Microsoft Systems Center Mobile Device Manager (SCMDM).

In questo articolo si parlerà parte le nozioni di base della tecnologia sottostante IKEv2 e MOBIKE. Si presuppone una conoscenza di IPv4 e rete, familiarità con i telefoni cellulari e una conoscenza di base della crittografia. In questo articolo non verrà per coprire IPsec in modo dettagliato e non è intende illustrare altri tipi di tecnologie VPN, ad esempio VPN basata su SSL. Inoltre non illustrare IPv6. IPsec e IKE sono estensioni per IPv4, ma viene salvati in IPv6, pertanto alcune delle operazioni che è verrà Accennare alle qui saranno comunque applicabili in una rete IPv6. Tuttavia, IPv6 introduce sufficiente complessità e di una nuova terminologia che non sarebbe possibile coprire sufficiente dettagliatamente.

Ad esempio ‘ AH ’

Tre protocolli costituiscono la base di IPsec: Authentication Header (AH), incapsulamento Security Payload (ESP) e IKE. Per risolvere IKE, È necessario prima discutere di AH ed ESP.

In poche parole, AH assicura che i pacchetti che verrà inviata non vengono alterati. Protegge l'integrità del nostro pacchetti. AH assicura inoltre che i pacchetti vengono inviati da chiunque dichiara di hanno inviato. Garantisce l'autenticità del nostro pacchetti. AH non tuttavia fornire qualsiasi misura di riservatezza o crittografia. Un utente malintenzionato che riesce ad accedere alla rete ancora impossibile lo sniffing di pacchetti che sono protetti mediante AH ed estrarre il contenuto. Non, tuttavia, potranno mascherarsi come una delle parti autenticate non essere in grado di modificare i pacchetti in transito. AH è definito in RFC 4302.

Ad esempio, Alice e Roberto stabilita una connessione VPN tra loro e scelto per proteggere i pacchetti con AH. Carlo inserisce l'eseguibile in rete e inizia la intercetta i pacchetti. Carlo è in grado di ricostruire la conversazione Alice e Luca poiché ha in grado di visualizzare il contenuto dei pacchetti e identificare il tipo di traffico passa tra di essi. Tuttavia, ha non contraffare un messaggio da Alice a Roberto senza rilevata durante il recupero e ha Impossibile modificare i messaggi di Roberto Alice, sia. Entrambe queste operazioni, sono impediti dal AH.

AH può essere utilizzato in modalità di trasporto o in modalità tunnel. Nella modalità di trasporto, il payload di un pacchetto viene protetto e i pacchetti vengono instradati direttamente da un host a altro. In modalità tunnel, l'intero pacchetto protetto da AH e i pacchetti vengono instradati una fine di un "tunnel" IPseca un altro. Tunneling avviene tramite l'incapsulamento del pacchetto originale. A entrambe le estremità del tunnel è un gateway di protezione. Il gateway che invia un pacchetto è responsabile di incapsulamento di tale pacchetto mediante l'aggiunta di un "esterno"Intestazione IP e indirizzo. Questo indirizzo esterno instrada il pacchetto al gateway di protezione a altra estremità del tunnel. Il gateway che riceve il pacchetto è responsabile dell'elaborazione di AH per determinare il pacchetto da un mittente valido e non è stato alterato e quindi instrada il pacchetto alla propria destinazione finale.

In modalità di trasporto, un AH ottiene aggiunto il pacchetto subito dopo l'intestazione IP. Il AH viene prima il protocollo di livello successivo nel pacchetto (ad esempio, UDP o TCP) e anche prima di altre intestazioni IPsec nel pacchetto, ad esempio l'intestazione ESP. È necessario il valore 51, ovvero il numero chiave assegnato da IANA per AH che indica l'applicazione di elaborazione del pacchetto che che verrà visualizzato è un AH per l'intestazione IP che precede il AH. Nella figura 1 mostra la forma di un pacchetto dopo che un AH aggiunto.

In modalità tunnel AH l'ottiene aggiunto dopo la nuova intestazione IP. L'intestazione IP incapsulata viene considerato come parte del payload, insieme con tutti gli altri elementi. Come illustrato in figura 2. I primi 8 bit di un pacchetto protetto da AH specificare l'ID di protocollo del payload dopo il AH. In questo modo il destinatario come previsto dopo il payload AH. Ad esempio, se il protocollo di livello successivo è TCP, l'ID di protocollo verrà impostata su 6. Questo campo è denominato l'intestazione successiva. (Si potrebbe essere evidente perché non è chiamato Protocol in modo coerente con altre intestazioni in IPv4. Il motivo è la coerenza e la compatibilità con IPv6. Fortunatamente, non è realmente necessario conoscere molto su IPv6 per comprendere il funzionamento AH sulla rete IPv4, ma se vi sono state chiedendo perché viene chiamato intestazione successiva, che perché).

Segue la lunghezza di 7 bit di payload AH. Poiché c'è solo a 7 bit, dimensione del payload è limitata a 128 byte. È quindi una lunga stringa di zero: 2 byte, in realtà. Questi 2 byte sono riservati per future in base alla RFC, così fino a che viene definito un utilizzo futuro, abbiamo 2 byte vuoti che sono semplicemente lungo il tragitto.

Dopo di questi 2 byte è l'indice SPI (Security Parameter Index). Questo è un numero a 32 bit viene utilizzato per determinare quale associazione di protezione IPsec (SA) è associato il AH. Verrà descritto in dettaglio sa quando verranno illustrati IKEv2. Questo numero è seguito da un numero di sequenza a 32 bit, che viene incrementato con ogni pacchetto inviato e viene utilizzato per impedire attacchi di riproduzione.

Dopo la sequenza di numero deriva Integrity Check Value (ICV). Il valore ICV viene calcolato al mittente applicando una funzione di hashing, ad esempio SHA-2, l'intestazione IP, il AH e il payload. Il ricevente verifica che il pacchetto non è stato alterato applicando la stessa funzione di hashing e conferma che viene generato lo stesso hash.

Dispone di ESP

Ad esempio AH, ESP (Encapsulating Security Payload) consentono di integrità e autenticazione. A differenza di AH, ESP offre tuttavia l'autenticazione e integrità solo per il payload del pacchetto, non per l'intestazione del pacchetto. ESP può essere utilizzato anche per garantire la riservatezza crittografando il payload del pacchetto. In teoria, queste funzionalità di ESP possono essere attivate in modo indipendente, pertanto è possibile utilizzare crittografia senza autenticazione e l'integrità, o per l'integrità e autenticazione senza crittografia. In pratica, tuttavia, in uno senza l'altro non rende molto senso. Ad esempio, sapendo che un messaggio è stato inviato a me riservatezza non non mi qualsiasi bene se Impossibile assicurarsi inoltre completamente che ha inviato. ESP è definito in RFC 4303.

ESP, come AH, può essere attivata in modalità tunnel o in modalità di trasporto. L'intestazione ESP deve essere inserito dopo il AH. In modalità di trasporto, ESP Crittografa il payload del pacchetto IP. In modalità tunnel ESP considera l'intero pacchetto incapsulato come payload e Crittografa. Questo scenario è illustrato nella Figura 3.

L'algoritmo di crittografia viene scelto tramite un processo di negoziazione tra i peer che il SA IPsec. Avanzate Encryption Standard (AES) è una scelta comune dell'algoritmo di crittografia per le implementazioni più recenti. Naturalmente, per utilizzare AES, è innanzitutto necessario un segreto condiviso per i due host che stanno per avviare una comunicazione protetta. Dando manualmente la chiave condivisa l'host infatti un approccio pratico non modificare la scala, ma è possibile utilizzare scambio di chiave Diffie-Hellman (DH) per effettuare il provisioning il segreto.

Gruppi Diffie-Hellman

DH è un protocollo che consente a due parti di condividono un segreto attraverso un canale non protetto ed è parte integrante della negoziazione viene eseguita in IKE. Il segreto condiviso viene comunicato tramite DH utilizzabile per creare un canale di comunicazione crittografato in modo protetto. I calcoli che va in DH sono complesso e non passerà in esso in dettaglio qui. Se si è interessati a ulteriori informazioni, controllare quali risorse che trattano modulari gruppi di (MODP) esponenziali e le applicazioni affinché DH. Per i nostri scopi, è sufficiente per dire che un gruppo DH è un insieme specifico di numeri con una relazione matematica e un ID di gruppo univoco.

Un gruppo DH viene specificato quando una connessione protetta impostata con IPsec, durante la negoziazione IKE. In questa negoziazione necessario trovare un gruppo DH che esse supportano i due peer tenta di stabilire una connessione protetta. Gruppi DH con ID superiore dispongono di più alto livello di crittografia. Ad esempio, i gruppi DH primo detti nella specifica IKE originale era sul livello di crittografia stesso come chiave simmetrica con comprese tra 70 e 80 bit. Con l'avvento di algoritmi di crittografia più avanzati, ad esempio AES, era necessario dai gruppi DH per impedire che i gruppi DH diventa un collegamento debole nella catena di crittografia più potenza. Pertanto, più recenti i gruppi di DH specificati nella RFC 3526 forniscono forza stimato tra 90 e 190 bit.

Lo svantaggio di questi gruppi DH più recenti è che le complessità maggiore presenta un costo: ai gruppi di protezione avanzati, è necessario più tempo di elaborazione. Questo è uno dei motivi perché il peer necessario per negoziare un gruppo DH reciprocamente accettabile. Ad esempio, il telefono non dispone potenza di elaborazione sufficiente per gestire il gruppo DH 15, in modo che si desidera supportare solo DH gruppo 2. Mentre tentando di stabilire una connessione IPsec con un server, il telefono propone DH gruppo 2 e se il server supporta DH gruppo 2, tale gruppo verrà utilizzato, anche se il server potrebbe potenzialmente hanno utilizzato il gruppo DH protezione più avanzata. Naturalmente, se i due peer non è possibile concordare un gruppo DH comune, non sarà in grado di comunicare.

È sufficiente sfondo. È possibile parlare di IKE.

LIKE IKE (e pertanto se si)

IKE viene utilizzato per stabilire una connessione IPsec tra i peer. Questa connessione viene chiamata un associazione di protezione (SA). Esistono due tipi di associazioni di protezione, il IKE_SA e il CHILD_SA. Il IKE_SA è impostato per prima. È il segreto condiviso è stato negoziato su DH e in cui vengono inoltre negoziate crittografia e algoritmi di hash. Il CHILD_SA è in cui viene inviato il traffico di rete, protetti mediante AH, ESP o entrambi.

Ogni richiesta in IKE richiede una risposta, che rende utile pensare in termini di coppie di messaggi. Utilizzata il primo messaggio coppia è chiamato IKE_SA_INIT e viene utilizzato per decidere quali algoritmo di crittografia e DH gruppo i peer. Poiché crittografia ancora viene determinata durante questo scambio, questa coppia di messaggio non crittografata. La coppia successiva di messaggi viene chiamata IKE_SA_AUTH. Questo scambio autentica i messaggi inviati durante IKE_SA_INT e dimostra l'identità del sia l'iniziatore e risponditore. Si serve di questo passaggio perché il primo messaggio è stato inviato in chiaro--avere stabilito un canale protetto, i peer ora necessario provare a loro che effettivamente siano chi affermano che sono e che si intende realmente avviare questa conversazione. Lo scambio di messaggi IKE_SA_AUTH inoltre imposta il primo CHILD_SA, che viene spesso il solo CHILD_SA creata tra i peer.

Un CHILD_SA è una connessione di simplex--oppure unidirezionale--, CHILD_SAs sono sempre impostare in coppie. Se viene eliminata una SA in una coppia, l'altro deve inoltre essere eliminato. Questa operazione è gestita tramite messaggi di informazione in IKE. Per RFC 4306, un messaggio di informazione contiene zero o più messaggi di notifica, Elimina o configurazione. Si supponga che abbiamo un iniziatore che un PC e un risponditore di un server. Il PC decide di chiudere la connessione CHILD_SA e terminare la connessione VPN. Invia un messaggio di informazione con un payload Elimina il server, che identifica il SA per eliminare dal proprio SPI. Quindi, il server Elimina questa SA in ingresso e invia una risposta al computer per eliminare la metà dell'associazione di protezione. Il computer riceve questo messaggio ed elimina la metà dell'associazione di protezione e tutto ciò che è molto utile.

Naturalmente, operazioni potrebbero non funzionare sempre in questo modo. O un iniziatore che un risponditore potrebbe terminare con un'associazione di protezione in un "metà chiuso"stato in cui un membro della coppia di SA viene chiusa ma l'altro è ancora aperto. La richiesta RFC specifica che questa è una condizione anomale, ma non consenta di un peer chiudere queste connessioni aperte a metà di per sé. Invece il peer deve eliminare il IKE_SA se lo stato della connessione diventa sufficientemente instabile--ma si il IKE_SA Elimina alf il CHILD_SAs che sono stati creati di sotto. Entrambi i casi sarebbe più complesso di un telefono mantenere aperto il CHILD_SA si consumano risorse di sistema scarse, come farebbe dover eliminare e rigenerare il IKE_SA.

Inoltre, è possibile che un peer alla fine di una SA venga rimosso completamente, senza che indica il sistema su altro lato dell'associazione di protezione è buona. Si tratta di una circostanza che è particolarmente soggetta a verificarsi con i telefoni cellulari. Si consideri, ad esempio, uno scenario in cui un telefono cellulare già una connessione VPN IPsec con un server. L'utente del telefono cellulare entra in un seminterrato e perde il segnale radio. Il server non dispone di alcun modo di sapere che il telefono è scomparsa in un black hole, in modo che continua a inviare messaggi di CHILD_A, ma non riceve nessuna risposta. Allo stesso modo sarebbe possibile per il telefono avviare l'invio di messaggi in un black hole causa di problemi di routing della rete del cellulare. Tutto ciò che potrebbe causare un peer non terrà traccia di un altro può causare questa condizione, ma il costo al telefono è maggiore del costo sul server, in quanto le risorse al telefono sono più limitate.

Perché È IT non valida per eliminare e rigenera l'associazione di protezione?

È la risposta breve strappo verso il basso e ricreare l'associazione di protezione utilizza risorse costose che il telefono can’t rimanere rifiuti. In particolare, l'esecuzione di calcoli di crittografici viene utilizzata la CPU e mentre la radio è in utilizzare invio e ricezione di grandi quantità di dati, che costo della batteria. La grande quantità di dati trasferiti anche consuma larghezza di banda, i costi di money, soprattutto in posizioni in cui i dati piani addebito per il kilobyte.

Poiché invia un messaggio sulla radio i costi di alimentazione e risparmio di energia sul telefono è limitato, il telefono deve rilevare queste situazioni di black hole e affrontare per risparmiare risorse di sistema. Questa operazione viene in genere gestita tramite un processo denominato inattività peer rilevamento (DPD), in cui un peer che si sospetta che potrebbe essere parla un black hole invia un messaggio di richiesta di liveness prova. Se la destinazione di questa richiesta non risponde entro un periodo di tempo appropriato, il mittente richieda l'azione appropriata per eliminare il IKE_SA e recuperare le risorse dedicate su di esso. In generale, è preferibile inviare messaggi DPD solo quando non c'è nessun altro traffico viaggia attraverso l'associazione di protezione e il peer ha motivo sospettare che partner l'associazione di protezione non è più presente. Mentre non vi è alcun requisito per implementare DPD in questo modo, non ha senso molto per confermare il liveness di un peer che attualmente di inviare altri tipi di traffico di rete.

Un'altra situazione che può causare problemi in una connessione VPN è un host che modifica l'indirizzo IP. L'indirizzo IP di un host viene utilizzato con l'indice SPI 32 bit per identificare un particolare host e associarlo a un'associazione di protezione. Quando un host perde l'indirizzo IP, questa associazione inoltre viene persa e l'associazione di protezione deve essere eliminato e ricrearli con il nuovo indirizzo IP.

Come abbiamo già detto prima, questo non è parte di un problema con desktop o portatili. Un computer potrebbe perdere il lease di DHCP e ottenere un nuovo indirizzo IP, ma la maggior parte delle implementazioni DHCP rischio piuttosto che che al PC verrà essere assegnato lo stesso indirizzo IP che aveva prima. In altre parole, PC desktop non consentire la modificare molto spesso gli indirizzi IP. I computer portatili, poiché sono mobili, è possibile modificare al punto di collegamento di rete e quindi generato un nuovo indirizzo IP, imporre qualsiasi SA che hanno aperto in venga distrutta e ricreata. Tuttavia, la frequenza con cui i computer portatili passare gli indirizzi IP è ancora relativamente occasionali quando viene confrontato con la frequenza con cui si è un telefono. Ad esempio, un telefono dotato di grado di trasmettere i dati tramite Wi-Fi e canali cellulari potrebbe passare reti ogni volta che un utente scorre nella o dalla propria edificio come il telefono passa da un Wi-Fi a una connessione GPRS e viceversa nuovamente. A differenza di un computer portatile spostamento di una palazzina, che potrebbe rimanere sul stesso collegamento di rete e pertanto continuare per un indirizzo di rete topologically corretto senza una modifica, il telefono è passato tra due reti fondamentalmente diverse, in modo che è praticamente garantita per modificare gli indirizzi IP. In questo modo una connessione interrotta al telefono ogni volta che si verifica un passaggio (handoff) tra le reti. La stessa cosa può verificarsi quando il telefono è in rete cellulare solo. Il telefono potrebbe modalità comune e passare dalla rete a una rete esterna di proprietà di un diverso operatore mobile. Il telefono potrebbe spostare da un'area di copertura a un altro e diventa collegato a una parte completamente diversa di rete dell'operatore mobile.

Esistono un numero qualsiasi di altri motivi applicando l'operatore mobile che potrebbe causare una connessione interrotta. Questa interruzione frequenti verso il basso e la ricostruzione dell'associazione di protezione renderebbe il mobile VPN intractable Impossibile per le estensioni per IKEv2 noto come MOBIKE.

MOBIKE

Il protocollo di IKEv2 MOBIKE è definito in RFC 4555. Consente di peer in una rete VPN IPsec per annunciare che dispongano di più indirizzi IP. Uno di questi indirizzi è associato di associazione di protezione per quel peer. Se il peer viene forzato a passare l'indirizzo IP causa di una modifica nell'allegato di rete, uno degli indirizzi IP identificati in precedenza, o un indirizzo appena assegnato, è possibile sostituire senza dover eliminare e ricreare l'associazione di protezione.

Per indicare la possibilità di utilizzare MOBIKE, un peer include una notifica MOBIKE_SUPPORTED nello scambio IKE_SA_AUTH. Lo scambio IKE_AUTH include inoltre gli indirizzi aggiuntivi per l'iniziatore e risponditore. L'iniziatore è la periferica avviata l'installazione di rete VPN mediante l'invio del primo messaggio IKE che è responsabile di prendere decisioni degli indirizzi IP da utilizzare tra quelle è disponibile e quelli offerti a esso, il risponditore.

Come indica la richiesta, l'iniziatore è in genere il dispositivo mobile poiché il dispositivo portatile presenta ulteriori consapevolezza della posizione della rete e di conseguenza è meglio adatto a prendere decisioni sulle quali indirizzi da utilizzare. Tuttavia, la richiesta non specifica come devono essere eseguite queste decisioni. In genere, una parte di IPsec VPN sarà un dispositivo mobile, e l'altra estremità sarà un server gateway di protezione fermo. La specifica non richiede l'implementazione e consente di entrambe le estremità del gateway per spostare, ma non fornisce un modo per le due estremità del gateway per ritrovare loro se lo spostamento nello stesso momento. Ovvero, se un peer Aggiorna l'indirizzo e l'altro peer non la stessa operazione nello stesso momento, non ha alcuna possibilità per comunicare la modifica con entrambi i peer, e la connessione VPN andranno persa.

L'iniziatore utilizza elenco di indirizzi del responder per scoprire la coppia di indirizzi migliore da utilizzare per l'associazione di protezione. Il risponditore non utilizza gli indirizzi dell'iniziatore, tranne come mezzo di comunicazione con l'iniziatore che l'indirizzo del responder è stato modificato.

Ad esempio, quando l'iniziatore rileva che l'indirizzo è stato modificato, notifica il responder del fatto un messaggio di informazione che contiene una notifica UPDATE_SA_ADDRESSES. Questo messaggio utilizza il nuovo indirizzo, avvia inoltre utilizzato nei messaggi di ESP del peer. Il destinatario della notifica di aggiornamento registra il nuovo indirizzo e, facoltativamente, verifica per routability restituito per assicurarsi che l'indirizzo appartiene a altro nodo mobile, come viene richiesto. In seguito, nel risponditore verrà avviato mediante il nuovo indirizzo per il traffico ESP in uscita.

L'iniziatore o risponditore naturalmente potrebbe non grado di tutti gli indirizzi IP che avrà mai per tutta la durata dell'associazione di protezione. Un peer possibile annunciare una modifica l'elenco di indirizzi che supporta con un messaggio di informazione. Se il peer ha un solo indirizzo, questo indirizzo è presente nell'intestazione e il messaggio contiene la notifica NO_ADDITIONAL_ADDRESSES. In caso contrario, se il peer ha più indirizzi, uno di questi indirizzi è inserire nell'intestazione del messaggio di informazione e gli altri sono inclusi in una notifica ADDITIONAL_IP4_ADDRESSES.

Questo elenco non è un aggiornamento--è l'intero elenco di indirizzi che il peer desidera annunciare in quel momento. In altre parole, l'intero elenco viene inviato ogni volta, ma questo costo è ancora inferiore il costo di strappo verso il basso e ricreare l'associazione di protezione ogni volta che il telefono cambia il punto di collegamento di rete.

Conclusioni

Ora è un'idea di base del funzionamento sarebbe un VPN IPsec con MOBIKE un telefono cellulare.

La prevalenza crescente di telefoni intelligenti nella home page e area di lavoro verrà per rendere queste soluzioni più importante quando gli utenti iniziano a richiesta un'esperienza corrispondente a quella su più dispositivi di elaborazione e ricco di risorse. Per il momento, gli utenti sono disposti a accettare i telefoni Impossibile connettersi alla rete azienda, che dispongono di un solo giorno di durata della batteria e che soffrono gli svantaggi del telefono smart che si conoscono tutte le altri. Questo non ultimo. Concorrenza e la diffusione di hardware migliore forzerà l'adozione delle soluzioni più complete, end-to-end che consentono di esperienze per il telefono paragonabile con il laptop e desktop.

E quindi, unitamente a tutti gli altri, sarà possibile visualizzare siti di SharePoint aziendali semplicemente selezionando un collegamento al telefono.

Speciali grazie a Melissa Johnson per suo suggerimenti e tecniche di revisione di questo articolo.

Ramon Arjona è un lead SDET presso Microsoft.