La notion de tunnel, en réseaux, est dure à saisir sans celle de "couche", centrale dans leur étude. Grossièrement, on modélise généralement les réseaux en une succession de couches logiques relativement indépendantes ; chaque couche est, disons, comme un logiciel différent, chargé de gérer une certaine partie de la communication. Il y en a donc plusieurs, et le plus simple est d'en distinguer quatre, car essentiellement, pour communiquer sur Internet, il faut, de "bas" (plus proche du matériel) en "haut" (plus proche des applications) :
Ces tâches ont peu de liens entre elles, dans le sens où elles appellent des outils et des concepts un peu différents, mais elles doivent absolument se faire un certain ordre (de "haut" en "bas" pour envoyer des donnés, et de "bas" en "haut" pour les recevoir : par exemple quand des données sont reçues, d'abord décoder le signal physique, puis décoder la destination dans le réseaux, puis si c'est soi-même, vérifier que tout est bien reçu, réordonner, et enfin envoyer à l'application qui saura comprendre les données reçues, comme un navigateur sait afficher une page web par exemple), d'où la notion de couches successives. Dans cette architecture, toutes les applications que l'on utilise se trouvent dans la plus haute, et afin d'avoir une chance d'arriver à destination, des données qu'une application veut envoyer traversent successivement toutes les autres couches pour être traitées, "emballées" (comme un collis à la poste) et adressées correctement.
À partir de ce modèle en couches, on peut définir correctement la notion de tunnel : c'est le principe d'insérer des données d'une couche inférieure (plus proche de la couche physique) dans une couche supérieure (plus proche de celle des applications), alors que cela va à l'encontre de l'architecture normale, par le biais d'un protocole et d'un logiciel dédiés. Par exemple, supposons que l'on veuille simuler un réseau local entre deux ordinateurs très éloignés l'un de l'autre, c'est-à-dire faire comme s'ils étaient directement reliés par un câble, alors qu'ils ont de nombreux routeurs entre eux. Pour se faire, on utilise un genre de câble virtuel : lorsque, par exemple, le premier ordinateur veut envoyer des données, il fait comme si un câble existait effectivement, il leur fait traverser toutes les couches et se retrouve avec des données prêtes à être envoyées dans un canal physique. Puis, au lieu de les envoyer, il les intègre, grâce à un bon protocole, dans des données de la couche la plus haute, celle des applications ; ces nouvelles données sont, elles, envoyées normalement à travers l'Internet (elles traversent à nouveaux toutes les couches pour cela), puis reçues par le second ordinateur qui décode tout et retrouve ainsi les données qui avaient été intégrées. Ce sont des donnés de la plus basse couche, le second ordinateur peut donc faire comme s'il venait de les recevoir depuis un canal physique, et les décoder comme il le ferait normalement. Pour l'application qui a envoyé les données initialement, tout s'est passé comme si un véritable câble reliait les deux ordinateurs.
Un tunnel permet donc de simuler un câble entre deux ordinateurs reliés par l'Internet ; plus généralement, on peut théoriquement faire des tunnels en intégrant n'importe quel protocole d'une certaine couche dans une autre couche, donc simuler autre chose qu'un câble, et éventuellement à travers des protocoles judicieusement choisis.
Par exemple, une application classique est de simuler un câble ou un petit réseau, mais en utilisant un protocole sécurisé où les données sont chiffrées ; c'est ce que fait OpenVPN. Cela empêche d'espionner de quelque façon que ce soit les données envoyées entre les deux bouts du tunnel (notons que cela n'a en revanche aucune influence sur ce qui se déroule hors du tunnel).
Un peu différent, le principe d'un tunnel "IP-over-DNS", comme le fait Iodine, est d'intégrer le protocole IP (c'est-à-dire n'importe quelle donnée envoyée dans un réseau, ce n'est pas la couche la plus basse mais pas loin) dans le protocole DNS (considéré dans notre modèle comme faisant partie de la plus haute couche, c'est une application) ; contrairement à ce que fait OpenVPN, l'approche ici est de détourner un protocole existant pour y insérer d'autres données, plutôt que d'utiliser un protocole spécialement conçu pour faire un tunnel. C'est beaucoup moins efficace, mais cela prend tout son sens quand seul le protocole détourné peut passer librement à travers un certain réseau, et aucun autre (comme le protocole DNS pour certains portails captifs des Wi-Fi ouverts). En revanche, c'est beaucoup moins sécurisé, les données ne sont par exemple pas cryptées, même s'il est possible de le faire... en utilisant un autre tunnel dans le tunnel DNS.
Un réseau privé virtuel est au tunnel - qui est, comme on l'a vu, un câble virtuel - ce qu'un réseau est à un câble simple : c'est un ensemble de tunnels reliés entre eux, généralement au niveau d'un serveur qui est un des bouts de chacun des tunnels. Ce serveur agit comme switch ou routeur pour ce réseau privé virtuel, simulant ainsi un véritable réseau à travers l'Internet, et généralement privé car les tunnels sont généralement cryptés.
Dans le cas d'une entreprise, ce serveur peut par exemple être relié à son Intranet, permettant un accès à l'Intranet sécurisé et "comme depuis l'intérieur de l'entreprise", grâce à un réseau privé virtuel.