Em relação a "como o computador reconhece este pacote como um pacote do Skype e não como um pacote da Web?": O pacote vai para qualquer programa que esteja escutando na porta. Se o Skype decidir usar o TCP / 80 e acidentalmente começar a falar com um servidor da Web, o servidor da Web ficará confuso, gerará um erro (ou se recusará a responder) eo Skype desistirá. Se um cliente da Web decidir se conectar ao Skype, o Skype verá a solicitação e reconhecerá que não é o Skype.
Isso significa que você não pode bloquear o Skype usando apenas as informações de IP / Porta. O bloqueio baseado no conteúdo com regras estáticas pressupõe que sempre haja uma assinatura fixa. Como o Skype é proprietário, o protocolo pode mudar a qualquer momento, tornando as regras antigas inúteis. O Skype é notoriamente bom em evitar filtros. Eu não ficaria surpreso se eles fizessem algo como adicionar uma chave aleatória no início e criptografar o resto do tráfego com a versão proprietária do RC4 do Skype, agora ou no futuro. Isso tornaria impossível distinguir o tráfego do ruído aleatório.
Com o tráfego da porta 443, eles também podem simplesmente executar uma conexão SSL real. Isso tornaria muito difícil distinguir (se feito corretamente) se você não quiser fazer análise de tráfego (como em "quantidade e tempo de tráfego"). Eu não sei se eles estão fazendo isso, mas novamente, o protocolo proprietário pode mudar.
A maneira mais confiável de impedir que os usuários usem o Skype pode verificar os executáveis nas máquinas e / ou usuários da LART que violam as políticas usando-os.
Verifique também o tráfego em outras portas. 80 e (mais provável "ou") 443 são provavelmente o mínimo que o Skype precisa. Pode ser feliz com algumas portas que você perdeu, mesmo que o 80/443 esteja completamente bloqueado. Verifique o tráfego UDP!