C'è un programma server in esecuzione dietro un modem / router ADSL domestico, in una premessa che chiamerò C ; il programma è in ascolto sulla porta TCP 29401 e accetta connessioni utilizzando un protocollo binario personalizzato, non HTTP , per lo scambio di dati. Il router di casa ha una funzione di port forwarding che è stata configurata per consentire (oltre a HTTP e SSH) le comunicazioni Internet con tale programma:

Outer port: TCP 29401
Inner port: TCP 29401
Server address: 192.168.1.196

Il modem / router ADSL domestico ha un IP pubblico dinamico sull'interfaccia esterna e utilizza il solito intervallo di indirizzi privati 192.168.1.X / 24 per la LAN. Il server esegue un client di aggiornamento automatico IP dinamico che mantiene aggiornato un record di host DNS (A). L'IP privato del server è 192.168.1.196. Lascia che dyn.example.com sia il nome del dominio DNS dinamico.

Mi concentrerò su uno scenario che coinvolge due premesse aggiuntive, che chiamerò A e B . Questi 3 locali non sono collegati e sono collegati in modo indipendente a Internet.

Premessa A

Dalla premessa A è possibile:

• Sfoglia il sito web corrispondente all'host virtuale dyn.example.com su Apache.
• SSH nel server utilizzando il nome host per stabilire la connessione
• Un programma client per il server binario personalizzato è in grado di connettersi a dyn.example.com:29401 e scambiare dati.
• Skype e altri software VOIP (che preferiscono utilizzare la perforatura) funzionano correttamente.
• Connetti a link e ricevi la pagina appropriata.

Premessa B

Dalla premessa B è possibile:

• Sfoglia il sito web corrispondente all'host virtuale dyn.example.com su Apache.
• Impossibile testare SSH, poiché nessun client SSH è disponibile in sede B .
• Lo stesso programma client si blocca, segnalando che la connessione è stata forzatamente chiusa dall'host remoto. Il server personalizzato non mostra alcuna prova di una connessione stabilita in qualsiasi punto.
• Skype e altri software VOIP (che preferiscono utilizzare la perforatura) funzionano correttamente.
• Connetti a link e ricevi la pagina appropriata.

La scelta di altre porte TCP comporta lo stesso comportamento.

Domanda

Le prove suggeriscono che a livello di applicazione B il traffico in uscita viene analizzato a livello di applicazione su tutte le porte TCP? Tutte le porte possono uscire, ma se provano a parlare usando un protocollo diverso da HTTP, il firewall termina la connessione. Per me questo è sorprendente perché ho sentito che prima un amministratore avrebbe bloccato tutte le porte e quindi avrebbe proceduto ad analizzare il traffico sulla porta 80 per impedire alle applicazioni di utilizzare le tecniche di tunneling HTTP .