Ecco il problema che sto cercando di risolvere. Esiste un server ("sistema remoto") sul quale sono in grado di accedere dal mio computer locale ma questo sistema remoto non ha una connessione a Internet. Voglio fornire al sistema remoto l'accesso a Internet tramite il mio computer locale tramite VPN basata su ssh. Come posso farlo? Ho provato quanto segue, che sembra funzionare parzialmente. Ciò che intendo per "lavoro parziale" è che i pacchetti di connessione (pacchetti di sincronizzazione) vengono inviati al mio computer locale ma non riescono a stabilire la connessione a Internet. Sto usando tcpdump per acquisire i pacchetti sul computer locale. Il computer locale e il sistema remoto eseguono entrambi centos 7.
L'installazione - Nota: i comandi seguenti vengono eseguiti in ordine. I comandi user @ remote vengono eseguiti sul server remoto e i comandi user @ local vengono eseguiti sul computer locale.
[user @ remote ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valido_lft per sempre preferito_lft per sempre
inet6 :: host ambito 1/128
valido_lft per sempre preferito_lft per sempre
2: eth0: mtu 1500 qdisc pfifo_fast stato UP qlen 1000
link / etere AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope eth0 dinamico globale
valid_lft 1785sec favorite_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope globale noprefixroute dinamico
valid_lft 2591987sec favorite_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: collegamento ambito LLLL / 64
valido_lft per sempre preferito_lft per sempre
[user @ local ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valido_lft per sempre preferito_lft per sempre
inet6 :: host ambito 1/128
valido_lft per sempre preferito_lft per sempre
2: eth0: mtu 1500 qdisc pfifo_fast stato UP qlen 1000
link / etere AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope eth0 dinamico globale
valid_lft 1785sec favorite_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope globale noprefixroute dinamico
valid_lft 2591987sec favorite_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: collegamento ambito LLLL / 64
valido_lft per sempre preferito_lft per sempre
Creare l'interfaccia tun0 sul sistema remoto .
[user @ remote ~] $ sudo ip tuntap aggiungi tun0 mode tun
[user @ remote ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valido_lft per sempre preferito_lft per sempre
inet6 :: host ambito 1/128
valido_lft per sempre preferito_lft per sempre
2: eth0: mtu 1500 qdisc pfifo_fast stato UP qlen 1000
link / etere AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope eth0 dinamico globale
valid_lft 1785sec favorite_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope globale noprefixroute dinamico
valid_lft 2591987sec favorite_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: collegamento ambito LLLL / 64
valido_lft per sempre preferito_lft per sempre
3: tun0: mtu 1500 qdisc noop stato DOWN qlen 500
Link / nessuno
Creare l'interfaccia tun0 sul sistema locale .
[user @ local ~] $ sudo ip tuntap aggiungi tun0 mode tun
[user @ local ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
inet 127.0.0.1/8 scope host lo
valido_lft per sempre preferito_lft per sempre
inet6 :: host ambito 1/128
valido_lft per sempre preferito_lft per sempre
2: eth0: mtu 1500 qdisc pfifo_fast stato UP qlen 1000
link / etere AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 scope eth0 dinamico globale
valid_lft 1785sec favorite_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope globale noprefixroute dinamico
valid_lft 2591987sec favorite_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: collegamento ambito LLLL / 64
valido_lft per sempre preferito_lft per sempre
3: tun0: mtu 1500 qdisc noop stato DOWN qlen 500
Link / nessuno
Assegna un indirizzo IP a tun0 e visualizzalo:
[user @ local ~] $ sudo ip addr aggiungi 10.0.2.1/30 dev tun0
[user @ local ~] $ sudo ip link set dev tun0 up
[user @ local ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast stato DOWN qlen 500
Link / nessuno
inet 10.0.2.1/30 scope global tun0
valido_lft per sempre preferito_lft per sempre
[user @ remote ~] $ sudo ip addr aggiunge 10.0.2.2/30 dev tun0
[user @ remote ~] $ sudo ip link set dev tun0 up
[user @ remote ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc pfifo_fast stato DOWN qlen 500
Link / nessuno
inet 10.0.2.2/30 scope global tun0
valido_lft per sempre preferito_lft per sempre
Modifica sshd_config su entrambi i sistemi remoto e locale per abilitare il tunneling:
[user @ remote ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config PermitTunnel punto-punto
[user @ local ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config PermitTunnel punto-punto
Crea il tunnel ssh:
[user @ local ~] $ sudo ssh -f -w0: 0 root @ remote true password di root @ remote: [utente @ locale ~] $ ps aux | grep root @ remote radice 1851 0,0 0,0 76112 1348? Ss 23:12 0:00 ssh -f -w0: 0 root @ remote true
Prova il ping su entrambi i server utilizzando i nuovi indirizzi IP:
[utente @ locale ~] $ ping 10.0.2.2 -c 2 PING 10.0.2.2 (10.0.2.2) 56 (84) byte di dati. 64 byte da 10.0.2.2: icmp_seq = 1 ttl = 64 tempo = 1,68 ms 64 byte da 10.0.2.2: icmp_seq = 2 ttl = 64 tempo = 0,861 ms --- 10.0.2.2 statistiche del ping --- 2 pacchetti trasmessi, 2 ricevuti, 0% perdita pacchetti, tempo 1002ms rtt min / avg / max / mdev = 0.861 / 1.274 / 1.688 / 0.415 ms
[user @ remote ~] $ ping 10.0.2.1 -c 2 PING 10.0.2.1 (10.0.2.1) 56 (84) byte di dati. 64 byte da 10.0.2.1: icmp_seq = 1 ttl = 64 tempo = 0,589 ms 64 byte da 10.0.2.1: icmp_seq = 2 ttl = 64 tempo = 0,889 ms --- 10.0.2.1 statistiche del ping --- 2 pacchetti trasmessi, 2 ricevuti, 0% perdita pacchetti, tempo 1000ms rtt min / avg / max / mdev = 0,589 / 0,739 / 0,889 / 0,150 ms
[user @ remote ~] $ route Tabella di routing IP del kernel Destinazione Gateway Maschera genetica Flag Metrico Rif Usa Iface gateway predefinito 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 U 0 0 0 tun0 AAA.BBB.CCC.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 [user @ remote ~] $ ip mostra percorso impostazione predefinita tramite AAA.BBB.CCC.1 dev eth0 proto static metric 100 10.0.2.0/30 dev tun0 proto kernel scope link src 10.0.2.2 AAA.BBB.CCC.0 / 24 dev eth0 proto kernel scope link src AAA.BBB.CCC.31 metrica 100
Ottieni indirizzi IP google:
[user @ local ~] $ nslookup google.com Server: server Indirizzo: server n. 53 Risposta non autorevole: Nome: google.com Indirizzo: 173.194.219.101 Nome: google.com Indirizzo: 173.194.219.100 Nome: google.com Indirizzo: 173.194.219.113 Nome: google.com Indirizzo: 173.194.219.102 Nome: google.com Indirizzo: 173.194.219.139 Nome: google.com Indirizzo: 173.194.219.138
IMPORTANTE: ho eseguito il comando sopra in un momento diverso e ho ottenuto un risultato diverso. Non dare per scontato che la tua risposta sarà uguale alla mia per nslookup sopra.
Poiché tutti gli indirizzi IP di Google iniziano con 173.194.219, consente di instradare tutti questi indirizzi IP attraverso il computer locale.
[user @ remote ~] $ sudo ip route add 173.194.219.0/24 dev tun0 [user @ remote ~] $ route Tabella di routing IP del kernel Destinazione Gateway Maschera genetica Flag Metrico Rif Usa Iface gateway predefinito 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 U 0 0 0 tun0 AAA.BBB.CCC.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 173.194.219.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 [user @ remote ~] $ ip mostra percorso impostazione predefinita tramite AAA.BBB.CCC.1 dev eth0 proto static metric 100 10.0.2.0/30 dev tun0 proto kernel scope link src 10.0.2.2 AAA.BBB.CCC.0 / 24 dev eth0 proto kernel scope link src AAA.BBB.CCC.31 metrica 100 173.194.219.0/24 dev tun0 scope link
Abilita ip_forwarding:
[user @ local ~] $ grep ip_forward /etc/sysctl.conf net.ipv4.ip_forward = 1 [user @ local ~] $ sudo riavvio della rete di servizi Riavvio della rete (tramite systemctl): [OK]
Acquisizione del pacchetto di installazione sul computer locale mediante tcpdump:
[user @ local ~] $ sudo tcpdump -nn -vv 'port not 22' -i any tcpdump: ascolto su qualsiasi LINUX_SLL di tipo link (Linux cotto), dimensione di acquisizione 65535 byte
Tentativo di connettersi a Google dal server remoto.
[user @ remote ~] $ openssl s_client -connect google.com:443 socket: nessuna route verso l'host Connect: errno = 113
Non appena il comando openssl viene eseguito sul server remoto, tcpdump acquisisce alcuni pacchetti:
10.0.2.2.52768> 173.194.219.102.443: Bandiere [S], cksum 0x8702 (corretto), seq 994650730, win 29200, opzioni [mss 1460, sackOK, TS val 7701438 ecr 0, nop, wscale 7], lunghezza 0
00: 49: 33.247753 IP (fino a 0x0, ttl 64, id 46037, offset 0, flag [DF], proto TCP (6), lunghezza 60)
10.0.2.2.48774> 173.194.219.100.443: Flags [S], cksum 0x47a7 (corretto), seq 2218733674, win 29200, opzioni [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], lunghezza 0
00: 49: 33.247883 IP (fino a 0xc0, ttl 64, id 9538, offset 0, flag [nessuno], proto ICMP (1), lunghezza 88)
10.0.2.1> 10.0.2.2: host ICMP 173.194.219.100 non raggiungibile - admin vietato, lunghezza 68
IP (fino a 0x0, ttl 63, id 46037, offset 0, flag [DF], proto TCP (6), lunghezza 60)
10.0.2.2.48774> 173.194.219.100.443: Flags [S], cksum 0x47a7 (corretto), seq 2218733674, win 29200, opzioni [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], lunghezza 0
00: 49: 33.253068 IP (fino a 0x0, ttl 64, id 26282, offset 0, flag [DF], proto TCP (6), lunghezza 60)
10.0.2.2.51312> 173.194.219.101.443: Flags [S], cksum 0x6ff8 (corretto), seq 2634016105, win 29200, opzioni [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], lunghezza 0
00: 49: 33.254771 IP (fino a 0xc0, ttl 64, id 9539, offset 0, flag [nessuno], proto ICMP (1), lunghezza 88)
10.0.2.1> 10.0.2.2: host ICMP 173.194.219.101 non raggiungibile - admin vietato, lunghezza 68
IP (fino a 0x0, ttl 63, id 26282, offset 0, flag [DF], proto TCP (6), lunghezza 60)
10.0.2.2.51312> 173.194.219.101.443: Flags [S], cksum 0x6ff8 (corretto), seq 2634016105, win 29200, opzioni [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], lunghezza 0
00: 49: 33.258805 IP (fino a 0x0, ttl 64, id 9293, offset 0, flag [DF], proto TCP (6), lunghezza 60)
10.0.2.2.33686> 173.194.219.139.443: Flags [S], cksum 0x542b (corretto), seq 995927943, win 29200, opzioni [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], lunghezza 0
00: 49: 33.258845 IP (fino a 0xc0, ttl 64, id 9540, offset 0, flag [nessuno], proto ICMP (1), lunghezza 88)
10.0.2.1> 10.0.2.2: host ICMP 173.194.219.139 non raggiungibile - admin vietato, lunghezza 68
IP (fino a 0x0, ttl 63, id 9293, offset 0, flag [DF], proto TCP (6), lunghezza 60)
10.0.2.2.33686> 173.194.219.139.443: Flags [S], cksum 0x542b (corretto), seq 995927943, win 29200, opzioni [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], lunghezza 0
^ C
13 pacchetti catturati
13 pacchetti ricevuti dal filtro
0 pacchetti rilasciati dal kernel
I pacchetti acquisiti utilizzando tcpdump suggeriscono che viene effettuato un tentativo di stabilire la connessione (i pacchetti di sincronizzazione vengono inviati) ma non viene ricevuto nulla. Inoltre c'è un messaggio 10.0.2.1 > 10.0.2.2: ICMP host 173.194.219.139 unreachable - admin prohibited, length 68che sembra suggerire un problema.
Qualche suggerimento su come aggirare questo problema? Ci sono regole iptable che devono essere aggiunte? Eventuali problemi con il firewall (firewall-d?).
Nota # 1
Output da iptables-save:
[user @ local ~] $ sudo iptables -t nat -A POSTROUTING -s 10.0.2.2/32! -d 10.0.2.1/30 -j MASQUERADE -o eth0 [utente @ locale ~] $ sudo iptables-save # Generato da iptables-save v1.4.21 di sabato 15 aprile 01:40:57 2017 * nat : PREROUTING ACCEPT [35: 8926] : INPUT ACCEPT [1:84] : OUTPUT ACCEPT [6: 439] : POSTROUTING ACCEPT [6: 439] : OUTPUT_direct - [0: 0] : POSTROUTING_ZONES - [0: 0] : POSTROUTING_ZONES_SOURCE - [0: 0] : POSTROUTING_direct - [0: 0] : POST_public - [0: 0] : POST_public_allow - [0: 0] : POST_public_deny - [0: 0] : POST_public_log - [0: 0] : PREROUTING_ZONES - [0: 0] : PREROUTING_ZONES_SOURCE - [0: 0] : PREROUTING_direct - [0: 0] : PRE_public - [0: 0] : PRE_public_allow - [0: 0] : PRE_public_deny - [0: 0] : PRE_public_log - [0: 0] -A PREROUTING -j PREROUTING_direct -A PREROUTING -j PREROUTING_ZONES_SOURCE -A PREROUTING -j PREROUTING_ZONES -A OUTPUT -j OUTPUT_direct -A POSTROUTING -j POSTROUTING_direct -A POSTROUTING -j POSTROUTING_ZONES_SOURCE -A POSTROUTING -j POSTROUTING_ZONES -A POSTROUTING -s 10.0.2.2/32! -d 10.0.2.0/30 -j MASQUERADE -A POSTROUTING_ZONES -o eth0 -g POST_public -A POSTROUTING_ZONES -g POST_public -A POST_public -j POST_public_log -A POST_public -j POST_public_deny -A POST_public -j POST_public_allow -A PREROUTING_ZONES -i eth0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow COMMETTERE # Completato sabato 15 aprile 01:40:57 2017 # Generato da iptables-save v1.4.21 di sabato 15 aprile 01:40:57 2017 * mangle : PREROUTING ACCEPT [169: 18687] : INPUT ACCEPT [144: 11583] : FORWARD ACCEPT [0: 0] : OUTPUT ACCEPT [80: 8149] : POSTROUTING ACCEPT [80: 8149] : FORWARD_direct - [0: 0] : INPUT_direct - [0: 0] : OUTPUT_direct - [0: 0] : POSTROUTING_direct - [0: 0] : PREROUTING_ZONES - [0: 0] : PREROUTING_ZONES_SOURCE - [0: 0] : PREROUTING_direct - [0: 0] : PRE_public - [0: 0] : PRE_public_allow - [0: 0] : PRE_public_deny - [0: 0] : PRE_public_log - [0: 0] -A PREROUTING -j PREROUTING_direct -A PREROUTING -j PREROUTING_ZONES_SOURCE -A PREROUTING -j PREROUTING_ZONES -A INPUT -j INPUT_direct -A FORWARD -j FORWARD_direct -A OUTPUT -j OUTPUT_direct -A POSTROUTING -j POSTROUTING_direct -A PREROUTING_ZONES -i eth0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow COMMETTERE # Completato sabato 15 aprile 01:40:57 2017 # Generato da iptables-save v1.4.21 di sabato 15 aprile 01:40:57 2017 *sicurezza : INPUT ACCEPT [2197: 163931] : FORWARD ACCEPT [0: 0] : OUTPUT ACCEPT [1229: 185742] : FORWARD_direct - [0: 0] : INPUT_direct - [0: 0] : OUTPUT_direct - [0: 0] -A INPUT -j INPUT_direct -A FORWARD -j FORWARD_direct -A OUTPUT -j OUTPUT_direct COMMETTERE # Completato sabato 15 aprile 01:40:57 2017 # Generato da iptables-save v1.4.21 di sabato 15 aprile 01:40:57 2017 *crudo : PREROUTING ACCEPT [2362: 184437] : OUTPUT ACCEPT [1229: 185742] : OUTPUT_direct - [0: 0] : PREROUTING_direct - [0: 0] -A PREROUTING -j PREROUTING_direct -A OUTPUT -j OUTPUT_direct COMMETTERE # Completato sabato 15 aprile 01:40:57 2017 # Generato da iptables-save v1.4.21 di sabato 15 aprile 01:40:57 2017 *filtro : INPUT ACCEPT [0: 0] : FORWARD ACCEPT [0: 0] : OUTPUT ACCEPT [80: 8149] : FORWARD_IN_ZONES - [0: 0] : FORWARD_IN_ZONES_SOURCE - [0: 0] : FORWARD_OUT_ZONES - [0: 0] : FORWARD_OUT_ZONES_SOURCE - [0: 0] : FORWARD_direct - [0: 0] : FWDI_public - [0: 0] : FWDI_public_allow - [0: 0] : FWDI_public_deny - [0: 0] : FWDI_public_log - [0: 0] : FWDO_public - [0: 0] : FWDO_public_allow - [0: 0] : FWDO_public_deny - [0: 0] : FWDO_public_log - [0: 0] : INPUT_ZONES - [0: 0] : INPUT_ZONES_SOURCE - [0: 0] : INPUT_direct - [0: 0] : IN_public - [0: 0] : IN_public_allow - [0: 0] : IN_public_deny - [0: 0] : IN_public_log - [0: 0] : OUTPUT_direct - [0: 0] -A INPUT -m conntrack --ctstate CORRELATO, STABILITO -j ACCETTA -A INGRESSO -i lo -j ACCETTA -A INPUT -j INPUT_direct -A INPUT -j INPUT_ZONES_SOURCE -A INPUT -j INPUT_ZONES -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -j REJECT - Rifiuta-con icmp-host-proibito -A AVANTI -m conntrack --ctstate CORRELATO, STABILITO -j ACCETTA -A AVANTI -i lo -j ACCETTA -A FORWARD -j FORWARD_direct -A FORWARD -j FORWARD_IN_ZONES_SOURCE -A FORWARD -j FORWARD_IN_ZONES -A FORWARD -j FORWARD_OUT_ZONES_SOURCE -A FORWARD -j FORWARD_OUT_ZONES -A AVANTI -m conntrack --ctstate INVALID -j DROP -A AVANTI -j REJECT - Rifiuta-con icmp-host-proibito -A OUTPUT -j OUTPUT_direct -A FORWARD_IN_ZONES -i eth0 -g FWDI_public -A FORWARD_IN_ZONES -g FWDI_public -A FORWARD_OUT_ZONES -o eth0 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FWDI_public -j FWDI_public_log -A FWDI_public -j FWDI_public_deny -A FWDI_public -j FWDI_public_allow -A FWDI_public -p icmp -j ACCETTA -A FWDO_public -j FWDO_public_log -A FWDO_public -j FWDO_public_deny -A FWDO_public -j FWDO_public_allow -A INPUT_ZONES -i eth0 -g IN_public -A INPUT_ZONES -g IN_public -A IN_public -j IN_public_log -A IN_public -j IN_public_deny -A IN_public -j IN_public_allow -A IN_public -p icmp -j ACCETTA -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT COMMETTERE # Completato sabato 15 aprile 01:40:57 2017
Nota n. 2:
ho installato un server web apache su un host separato a cui solo il server locale ha accesso. Ho eseguito tcpdump sul server Web in ascolto sulla porta 80. Quando eseguo,
telnet webserver 80acquisisco i seguenti pacchetti. Questo è un comportamento previsto poiché è stata stabilita la connessione TCP (S, S-Ack, Ack).
[user @ webserver ~] $ sudo tcpdump -nn -vv 'port not 22 and 80' -i eth0
tcpdump: ascolto su eth0, tipo di collegamento EN10MB (Ethernet), dimensione di acquisizione 65535 byte
07: 17: 30.411474 IP (fino a 0x10, ttl 64, id 34376, offset 0, flag [DF], proto TCP (6), lunghezza 60)
local.server.46710> web.server.80: Flags [S], cksum 0x8412 (errato -> 0x6d96), seq 3018586542, win 29200, opzioni [mss 1460, sackOK, TS val 3047398 ecr 0, nop, wscale 7] , lunghezza 0
07: 17: 30.411557 IP (fino a 0x0, ttl 64, id 0, offset 0, flag [DF], proto TCP (6), lunghezza 60)
web.server.80> local.server.46710: Flags [S.], cksum 0x8412 (errato -> 0x9114), seq 2651711943, ack 3018586543, win 28960, opzioni [mss 1460, sackOK, TS val 37704524 ecr 3047398, nop , scala 7], lunghezza 0
07: 17: 30.411725 IP (fino a 0x10, ttl 64, id 34377, offset 0, flag [DF], proto TCP (6), lunghezza 52)
local.server.46710> web.server.80: Flags [.], cksum 0x840a (errato -> 0x301c), seq 1, ack 1, win 229, opzioni [nop, nop, TS val 3047398 ecr 37704524], lunghezza 0
Quando provo a connettermi al server web dal server remoto attraverso il server locale, tcpdump sul server web non acquisisce alcun pacchetto (nemmeno la sincronizzazione iniziale) ma il server locale acquisisce il pacchetto Sync inviato al server web (vedi sotto). Questo mi fa credere che qualcosa impedisce ai pacchetti di essere inviati al server web, forse una configurazione errata o un firewall.
[user @ local ~] $ sudo tcpdump -nn -vv 'port not 22 and 80' -i any
tcpdump: ascolto su qualsiasi LINUX_SLL di tipo link (Linux cotto), dimensione di acquisizione 65535 byte
02: 24: 09.135842 IP (fino a 0x10, ttl 64, id 38062, offset 0, flag [DF], proto TCP (6), lunghezza 60)
10.0.2.2.50558> web.server.80: Flags [S], cksum 0x668d (corretto), seq 69756226, win 29200, opzioni [mss 1460, sackOK, TS val 4780524 ecr 0, nop, wscale 7], lunghezza 0
IMPORTANTE: i pacchetti non vengono instradati attraverso eth0 ma si tenta invece di inviare i pacchetti al server Web tramite tun0 (che non riesce). Posso confermarlo eseguendo tcpdump sull'interfaccia tun0:
[user @ local ~] $ sudo tcpdump -nn -vv 'port not 22 and 80' -i tun0
tcpdump: ascolto su tun0, RAW di tipo link (Raw IP), dimensione di acquisizione 65535 byte
02: 28: 10.295972 IP (fino a 0x10, ttl 64, id 46976, offset 0, flag [DF], proto TCP (6), lunghezza 60)
10.0.2.2.50560> webserver.80: Flags [S], cksum 0xd560 (corretto), seq 605366388, win 29200, opzioni [mss 1460, sackOK, TS val 5021684 ecr 0, nop, wscale 7], lunghezza 0
Nota n. 3:
ho disattivato firewalld nel computer locale e i pacchetti di sincronizzazione sono stati ricevuti dal server web.
[user @ local ~] $ sudo systemctl stop firewalld
[user @ webserver ~] $ sudo tcpdump -nn -vv 'port not 22 and 80' -i eth0
tcpdump: ascolto su eth0, tipo di collegamento EN10MB (Ethernet), dimensione di acquisizione 65535 byte
08: 25: 17.390912 IP (fino a 0x10, ttl 63, id 61767, offset 0, flag [DF], proto TCP (6), lunghezza 60)
10.0.2.2.50580> web.server.80: Flags [S], cksum 0x30dc (corretto), seq 2601927549, win 29200, opzioni [mss 1460, sackOK, TS val 7123514 ecr 0, nop, wscale 7], lunghezza 0
08: 25: 17.391003 IP (fino a 0x0, ttl 64, id 0, offset 0, flag [DF], proto TCP (6), lunghezza 60)
web.server.80> 10.0.2.2.50580: Flags [S.], cksum 0x4e23 (errato -> 0xa316), seq 959115533, ack 2601927550, win 28960, opzioni [mss 1460, sackOK, TS val 41771503 ecr 7123514, nop , scala 7], lunghezza 0
08: 25: 17.391192 IP (fino a 0x0, ttl 128, id 60032, offset 0, flag [nessuno], proto TCP (6), lunghezza 40)
10.0.2.2.50580> web.server.80: Flags [R], cksum 0x7339 (corretto), seq 2601927550, vittoria 8192, lunghezza 0
08: 25: 18.393794 IP (fino a 0x10, ttl 63, id 61768, offset 0, flag [DF], proto TCP (6), lunghezza 60)
10.0.2.2.50580> web.server.80: Flags [S], cksum 0x2cf1 (corretto), seq 2601927549, win 29200, opzioni [mss 1460, sackOK, TS val 7124517 ecr 0, nop, wscale 7], lunghezza 0
08: 25: 18.393898 IP (fino a 0x0, ttl 64, id 0, offset 0, flag [DF], proto TCP (6), lunghezza 60)
web.server.80> 10.0.2.2.50580: Flags [S.], cksum 0x4e23 (errato -> 0x7e71), seq 974785773, ack 2601927550, win 28960, opzioni [mss 1460, sackOK, TS val 41772506 ecr 7124517, nop , scala 7], lunghezza 0
08: 25: 18.394003 IP (fino a 0x0, ttl 128, id 60033, offset 0, flag [nessuno], proto TCP (6), lunghezza 40)
10.0.2.2.50580> web.server.80: Flags [R], cksum 0x566a (corretto), seq 2601927550, vittoria 8192, lunghezza 0
Ora chiaramente, l'IP di origine deve essere aggiornato in modo che corrisponda all'indirizzo IP del server locale prima che il pacchetto venga inviato al server web. Come suggerito da @xin, NAT deve essere configurato sul server locale.
Nota n. 4:
quando provo a connettermi al server web, vedo che i pkts contano per la regola 9 sale di 1 (come visto sotto).
[user @ local ~] $ sudo iptables -nvL --line-numbers .......... Chain FORWARD (politica ACCETTA 0 pacchetti, 0 byte) num byte byte destinazione prot opt in out destinazione di origine 1 0 0 ACCETTA tutto - * * 0.0.0.0/0 0.0.0.0/0 ctstate CORRELATO, STABILITO 2 0 0 ACCETTA tutto - lo * 0.0.0.0/0 0.0.0.0/0 3 1 60 FORWARD_direct all - * * 0.0.0.0/0 0.0.0.0/0 4 1 60 FORWARD_IN_ZONES_SOURCE tutto - * * 0.0.0.0/0 0.0.0.0/0 5 1 60 FORWARD_IN_ZONES tutti - * * 0.0.0.0/0 0.0.0.0/0 6 1 60 FORWARD_OUT_ZONES_SOURCE tutto - * * 0.0.0.0/0 0.0.0.0/0 7 1 60 FORWARD_OUT_ZONES tutti - * * 0.0.0.0/0 0.0.0.0/0 8 0 0 DROP all - * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID 9 1 60 REJECT all - * * 0.0.0.0/0 0.0.0.0/0 rifiuto-con icmp-host-proibito .......... [user @ local ~] $ sudo iptables -D FORWARD 9
Una volta eliminata la regola 9 dalla catena FORWARD (dall'alto, come suggerito da @xin), sono in grado di connettermi al server web.
[user @ local ~] $ sudo iptables -nvL --line-numbers .......... Chain FORWARD (politica ACCETTA 1 pacchetti, 60 byte) num byte byte destinazione prot opt in out destinazione di origine 1 12 5857 ACCETTA tutto - * * 0.0.0.0/0 0.0.0.0/0 ctstate CORRELATO, STABILITO 2 0 0 ACCETTA tutto - lo * 0.0.0.0/0 0.0.0.0/0 3 2 120 FORWARD_direct all - * * 0.0.0.0/0 0.0.0.0/0 4 2 120 FORWARD_IN_ZONES_SOURCE tutto - * * 0.0.0.0/0 0.0.0.0/0 5 2 120 FORWARD_IN_ZONES tutti - * * 0.0.0.0/0 0.0.0.0/0 6 2 120 FORWARD_OUT_ZONES_SOURCE tutto - * * 0.0.0.0/0 0.0.0.0/0 7 2 120 FORWARD_OUT_ZONES tutti - * * 0.0.0.0/0 0.0.0.0/0 8 0 0 DROP all - * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID ..........