L2TP
O uso do L2TP foi considerado, para substituir o uso do GRE, de forma que o túnel entre os switches não usasse camada 3 (rede), mas sim camada 4 (transporte), visto o problema ocasionado pelo NAT que nos obrigava a usarmos os modens da estrutura em modo bridge e executar o PPPoE diretamente nos clientes do chat, e limitava o uso do ETArch em algumas redes, nas quais não é possível este modo de conexão, além de complicar a configuração por exigir alterações diretas no modem. O uso deste protocolo foi descartado pois as soluções disponíveis (xL2TP) não foram concebidas para o uso individual, precisaríamos colocar um protocolo de criptografia (como IPsec), ou seja, funcionaria como um túnel IP, e como precisamos de um túnel camada 2, ainda assim seria necessário o uso do GRE, o que implica em um grande overhead para a solução.
VTUN
O VTUN, assim como o L2TP, tem o mesmo propósito na estrutura usada para a execução do chat, ou seja, criar um túnel de cadama sobre a camada 4. Este software permite a criação de vários tipos de túneis, dentre eles, o ethernet. Neste caso o túnel é criado de forma simples, e não tem dependências de outros protocolos ou softwares. Sua estrutura funciona entre clientes e servidor, na qual os túneis são criados entre ambos. Após a criação do túnel, uma nova interface é criada na máquina (tap0) nos dois pontos da conexão, e usando o openvswitch da mesma forma em que estruturamos no GRE, substituímos a interface "gre0" criada no switch, pela tap0.
Testes com o VTUN
Realizamos vários testes, em alguns obtivemos êxito, em outros não. Seguem:
- Primeiramente, com duas máquinas (clientes/switches) e o controlador em uma rede local. O VTUN foi executado entre estes duas máquinas, uma como servidor VTUN e outra como cliente VTUN. Foi observado neste caso que após a execução do chat, tudo funcionou normalmente.
- No segundo teste, tentamos executar entre duas casas, a diferença do primeiro é que todos possuiam IP válido. Neste caso o túnel funciona normalmente, é possível ver a troca dos pacotes LLDP entre os switches, mas no momento em que executamos o chat, as entidades e o workspace não são registrados no controlador.
- No terceiro teste, executamos o mesmo caso do segundo teste de uma forma simplificada, todos possuiam IPs válidos e estavam na mesma subrede. Novamente o túnel funcionou normalmente, com a troca dos pacotes LLDP, mas apresentou o mesmo problema do caso anterior (olhando no log do servidor, é possível ver as requisições enviadas logo após a execução do chat para o registro das entidades, mas o controlador não devolve reposta).