Distribuiremo una nuova applicazione su un server e l'applicazione ascolterà sulla porta 8443. Abbiamo chiesto al team di rete di aprire il firewall per la porta 8443 su quel server prima di distribuire l'applicazione. Al momento non esiste alcuna applicazione in ascolto su quella particolare porta sul server.
Esiste comunque un modo per assicurarmi che il firewall sia aperto per la porta 8443
Sistema operativo: Linux / Windows
Risposte:
Se vuoi vedere se riesci a formare una connessione TCP da un computer remoto, installa OpenCSW su quello e sul computer di destinazione e installa netcat su entrambi. Questa è la sintassi per l'uso di netcat per testare le connessioni TCP:
nc -vz targetServer portNum
Ad esempio per controllare SSH su "homeServer1":
nc -vz homeserver1 22
Ciò consente di testare la connettività a livello TCP dal sistema remoto. Netcat può anche essere configurato per l'ascolto su una porta piuttosto che come client. Per farlo ascoltare su TCP / 8443:
Sul server che ospiterà l'applicazione: nc -l homeserver1 8443
Su una macchina che si trova all'esterno del firewall: nc -vz homeserver.fqdn 8443
Questo è un esempio di esecuzione riuscita:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
Connection to ditirlns01.ncat.edu 8443 port [tcp/pcsync-https] succeeded!
Un'esecuzione non riuscita:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
nc: connect to ditirlns01.ncat.edu port 8443 (tcp) failed: Connection refused
I firewall devono rispondere con un messaggio ICMP quando bloccano una richiesta. Tuttavia, questo non è necessariamente il caso (sarai interessato a questo simpatico articolo ).
Puoi testare dall'esterno per vedere se una porta è accessibile attraverso un firewall e, in tal caso, se qualcosa è in ascolto su di essa. Ecco tre diversi scenari che coinvolgono una richiesta TCC che puoi osservare con wireshark, o qualche altro sniffer di pacchetti, e cosa vedrai:
1) Firewall rifiuta la richiesta
Riceverai un messaggio ICMP e lo strumento che effettua la richiesta dovrebbe dirti immediatamente qualcosa in tal senso ("irraggiungibile, amministratore vietato" ecc.) Per "strumento" intendo il client che stai utilizzando per inviare la richiesta (che ho usato telnet). I dettagli del messaggio 1 dipendono da come è configurato il firewall, ma "porta non raggiungibile" è probabilmente il più comune.
"Nessuna route verso l'host" può indicare questo, ma può anche indicare problemi di routing più sottili.
2) Firewall rilascia pacchetto
Non c'è risposta, quindi lo strumento attende fino al timeout o ti annoi.
3) Il firewall consente il pacchetto (o non esiste un firewall), ma nulla è in ascolto sulla porta.
Riceverai un messaggio TCP RST / ACK. Presumo che il protocollo TCP lo richieda. In altre parole, se nulla è in ascolto sulla porta, il sistema operativo stesso invia questa risposta. Potrebbe essere difficile distinguerlo dal n. 1 in base a ciò che riporta uno strumento, perché potrebbe dire la stessa cosa in entrambi i casi (tuttavia, molto probabilmente lo distingue come "connessione rifiutata" rispetto al n. 1, "rete non raggiungibile" ). Osservato in uno sniffer di pacchetti sul computer client, lo scenario n. 1 (messaggio di rifiuto ICMP) e n. 3 (messaggio TCP RST / ACK) sono chiaramente distinti.
L'unica altra opzione qui è che il pacchetto è autorizzato dal firewall e qualcosa è in ascolto, in modo da ottenere una connessione corretta.
In altre parole: presumendo che la rete in generale funzioni correttamente, se si ottiene il numero 1 o il numero 2, significa che un firewall impedisce attivamente l'accesso alla porta. # 3 accadrà se il tuo server non è in esecuzione ma la porta è accessibile, e ovviamente (l'implicito) # 4 è una connessione riuscita.
Puoi usare il comando netstatper vedere se una porta è aperta e in ascolto.
$ netstat -anp | less
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:41716 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:17500 0.0.0.0:* LISTEN 3034/dropbox
tcp 0 0 0.0.0.0:17501 0.0.0.0:* LISTEN 3033/dropbox
tcp 0 0 127.0.0.1:2143 0.0.0.0:* LISTEN 3191/ssh
tcp 0 0 127.0.0.1:2025 0.0.0.0:* LISTEN 3191/ssh
L'output mostra i processi (colonna più a destra) in ascolto su porte TCP. I numeri di porta sono i numeri che seguono i due punti dopo gli indirizzi IP (0.0.0.0:111 sarebbe la porta 111 per esempio).
Gli indirizzi IP mostrano indirizzi locali ed esteri . Locale sarebbe il tuo sistema mentre Foreign sarebbe qualsiasi indirizzo che si connettesse alla tua porta TCP o che ti connettessi a una delle loro porte TCP.
Quindi nel caso della porta 22, questo è il demone ssh in esecuzione sul mio sistema, questo è ASCOLTARE le connessioni. Una volta che qualcuno tenta di connettersi al sshdemone, crea una copia di se stesso e trasferisce la connessione su un'altra porta, mantenendo la porta TCP 22 aperta per ulteriori connessioni non appena arrivano.
netstat -a -P tcp -f inet | awk '/LISTEN$/ {print $0}'
La configurazione e lo stato della configurazione del firewall sono specifici del firewall / SO.
Quello che puoi fare è provarlo da server2:
nmap server1
Di recente ho ricevuto la stessa richiesta e sono arrivato al thread. Sono stato in grado di scansionare le porte aperte sull'FW con il comando nc, in questo modo mentre interrogo il suo output:
nc -v -w 1 -z -s *srcIP destIP port* 2>&1 | grep timed > /dev/null && echo closed || echo open
Fondamentalmente, se ricevo il "timeout" significa che la porta non è aperta sull'FW.
ncvenga segnalato "Connessione rifiutata" quando la porta è accessibile, ma non è presente un listener e "Rete non raggiungibile" quando la richiesta è stata rimbalzata da un firewall tramite icmp (il che significa che potrebbe esserci o meno un servizio sulla porta ). Se il firewall rilascia il pacchetto invece di rifiutarlo, sincbloccherà per un po '.