Как создать / настроить vpn, используя только SSH?

Вот проблема, которую я пытаюсь решить. Существует сервер («удаленная система»), с которого я могу подключиться к удаленному компьютеру, но у этой удаленной системы нет подключения к Интернету. Я хочу предоставить удаленной системе доступ к Интернету через локальный компьютер с использованием VPN на основе ssh. Как это сделать? Я пробовал следующее, что, похоже, частично работает. То, что я подразумеваю под «частично работать», это то, что пакеты соединений (пакеты синхронизации) отправляются на мой локальный компьютер, но не удается установить соединение с Интернетом. Я использую tcpdump для захвата пакетов на локальном компьютере. Локальный компьютер и удаленная система работают как CentOS 7.

Настройка – Примечание: приведенные ниже команды выполняются по порядку. Удаленные команды пользователя @ выполняются на удаленном сервере, а локальные команды user @ выполняются на локальном компьютере.

  [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
        valid_lft forever preferred_lft навсегда
     inet6 :: 1/128 область хоста 
        valid_lft forever preferred_lft навсегда
 2: eth0: mtu 1500 qdisc pfifo_fast состояние UP qlen 1000
     link / ether AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
     inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 область глобального динамического eth0
        valid_lft 1785sec preferred_lft 1785sec
     inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope global noprefixroute dynamic 
        valid_lft 2591987sec preferred_lft 604787sec
     inet6 ABCD :: IIII: JJJJ: KKKK: ссылка LLLL / 64 
        valid_lft forever preferred_lft навсегда
  [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
        valid_lft forever preferred_lft навсегда
     inet6 :: 1/128 область хоста 
        valid_lft forever preferred_lft навсегда
 2: eth0: mtu 1500 qdisc pfifo_fast состояние UP qlen 1000
     link / ether AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
     inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 область глобального динамического eth0
        valid_lft 1785sec preferred_lft 1785sec
     inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope global noprefixroute dynamic 
        valid_lft 2591987sec preferred_lft 604787sec
     inet6 ABCD :: IIII: JJJJ: KKKK: ссылка LLLL / 64 
        valid_lft forever preferred_lft навсегда

Создайте интерфейс tun0 на удаленной системе.

  [user @ remote ~] $ sudo ip tuntap add 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
        valid_lft forever preferred_lft навсегда
     inet6 :: 1/128 область хоста 
        valid_lft forever preferred_lft навсегда
 2: eth0: mtu 1500 qdisc pfifo_fast состояние UP qlen 1000
     link / ether AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
     inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 область глобального динамического eth0
        valid_lft 1785sec preferred_lft 1785sec
     inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope global noprefixroute dynamic 
        valid_lft 2591987sec preferred_lft 604787sec
     inet6 ABCD :: IIII: JJJJ: KKKK: ссылка LLLL / 64 
        valid_lft forever preferred_lft навсегда
 3: tun0: mtu 1500 qdisc noop состояние DOWN qlen 500
     не ссылка / нет 

Создайте интерфейс tun0 в локальной системе.

  [user @ local ~] $ sudo ip tuntap добавить tun0 режим 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
        valid_lft forever preferred_lft навсегда
     inet6 :: 1/128 область хоста 
        valid_lft forever preferred_lft навсегда
 2: eth0: mtu 1500 qdisc pfifo_fast состояние UP qlen 1000
     link / ether AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
     inet AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 область глобального динамического eth0
        valid_lft 1785sec preferred_lft 1785sec
     inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 scope global noprefixroute dynamic 
        valid_lft 2591987sec preferred_lft 604787sec
     inet6 ABCD :: IIII: JJJJ: KKKK: ссылка LLLL / 64 
        valid_lft forever preferred_lft навсегда
 3: tun0: mtu 1500 qdisc noop состояние DOWN qlen 500
     не ссылка / нет

Назначьте ip-адрес tun0 и поднимите его:

  [user @ local ~] $ sudo ip addr добавить 10.0.2.1/30 dev tun0
 [user @ local ~] $ sudo ip link set dev tun0 up
 [user @ local ~] $ ip addr показать tun0
 3: tun0: mtu 1500 qdisc pfifo_fast состояние DOWN qlen 500
     не ссылка / нет 
     inet 10.0.2.1/30 scope global tun0
        valid_lft forever preferred_lft навсегда 
  [user @ remote ~] $ sudo ip addr добавить 10.0.2.2/30 dev tun0
 [user @ remote ~] $ sudo ip link set dev tun0 up
 [user @ remote ~] $ ip addr показать tun0
 3: tun0: mtu 1500 qdisc pfifo_fast состояние DOWN qlen 500
     не ссылка / нет 
     inet 10.0.2.2/30 scope global tun0
        valid_lft forever preferred_lft навсегда

Измените sshd_config как на удаленных, так и на локальных системах, чтобы включить туннелирование:

  [user @ remote ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config 
 PermitTunnel точка-точка 
  [user @ local ~] $ sudo grep PermitTunnel / etc / ssh / sshd_config 
 PermitTunnel точка-точка

Создайте туннель ssh:

  [user @ local ~] $ sudo ssh -f -w0: 0 root @ remote true
 пароль root @ remote: 
 [user @ local ~] $ ps aux |  grep root @ remote
 корень 1851 0.0 0.0 76112 1348?  Ss 23:12 0:00 ssh -f -w0: 0 root @ remote true

Тестирование ping на обоих серверах с использованием новых IP-адресов:

  [user @ local ~] $ ping 10.0.2.2 -c 2
 PING 10.0.2.2 (10.0.2.2) 56 (84) байт данных.
 64 байт из 10.0.2.2: icmp_seq = 1 ttl = 64 раз = 1,68 мс
 64 байт из 10.0.2.2: icmp_seq = 2 ttl = 64 раз = 0,861 мс

 --- 10.0.2.2 статистика ping ---
 2 переданных пакета, 2 принятых, 0% потери пакетов, время 1002ms
 rtt min / avg / max / mdev = 0.861 / 1.274 / 1.688 / 0.415 мс
  [user @ remote ~] $ ping 10.0.2.1 -c 2
 PING 10.0.2.1 (10.0.2.1) 56 (84) байта данных.
 64 байт из 10.0.2.1: icmp_seq = 1 ttl = 64 раз = 0,589 мс
 64 байт из 10.0.2.1: icmp_seq = 2 ttl = 64 раз = 0.889 мс

 --- 10.0.2.1 статистика ping ---
 2 переданных пакета, 2 принятых, 0% потери пакетов, время 1000 мс
 rtt min / avg / max / mdev = 0,589 / 0,739 / 0,889 / 0,150 мс 
 [user @ remote ~] $ route
 Таблица маршрутизации IP ядра
 Назначение Gateway Genmask Flags Metric Ref Используйте Iface
 шлюз по умолчанию 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 route show
 по умолчанию через 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 ссылка src AAA.BBB.CCC.31 метрика 100 

Получить IP-адреса google:

 [user @ local ~] $ nslookup google.com
 Сервер: сервер
 Адрес: сервер № 53

 Неавторитетный ответ:
 Имя: google.com
 Адрес: 173.194.219.101
 Имя: google.com
 Адрес: 173.194.219.100
 Имя: google.com
 Адрес: 173.194.219.113
 Имя: google.com
 Адрес: 173.194.219.102
 Имя: google.com
 Адрес: 173.194.219.139
 Имя: google.com
 Адрес: 173.194.219.138

ВАЖНО: я запустил вышеуказанную команду в другое время и получил другой результат. Не предполагайте, что ваш ответ будет таким же, как мой для nslookup выше.

Поскольку все IP-адреса google начинаются с 173.194.219, можно маршрутизировать все эти IP-адреса через локальный компьютер.

 [user @ remote ~] $ sudo ip route добавить 173.194.219.0/24 dev tun0
 [user @ remote ~] $ route
 Таблица маршрутизации IP ядра
 Назначение Gateway Genmask Flags Metric Ref Используйте Iface
 шлюз по умолчанию 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 route show
 по умолчанию через 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 ссылка src AAA.BBB.CCC.31 метрика 100 
 173.194.219.0/24 dev tun0 scope link 

Включить ip_forwarding:

 [user @ local ~] $ grep ip_forward /etc/sysctl.conf 
 net.ipv4.ip_forward = 1
 [user @ local ~] $ перезагрузка сети sudo
 Перезапуск сети (через systemctl): [OK]

Настройка захвата пакетов на локальном компьютере с помощью tcpdump:

 [user @ local ~] $ sudo tcpdump -nn -vv 'порт не 22' -i любой
 tcpdump: прослушивание любого типа LINUX_SLL (Linux готово), размер захвата 65535 байт

Попытайтесь подключиться к Google с удаленного сервера.

 [user @ remote ~] $ openssl s_client -connect google.com:443
 socket: нет маршрута к хосту
 подключения: ERRNO = 113

Как только команда openssl запускается на удаленном сервере, tcpdump захватывает некоторые пакеты:

     10.0.2.2.52768> 173.194.219.102.443: Флаги [S], cksum 0x8702 (исправлено), seq 994650730, win 29200, опции [mss 1460, sackOK, TS val 7701438 ecr 0, nop, wscale 7], длина 0
 00: 49: 33.247753 IP (tos 0x0, ttl 64, id 46037, смещение 0, флаги [DF], протокол TCP (6), длина 60)
     10.0.2.2.48774> 173.194.219.100.443: флаги [S], cksum 0x47a7 (исправлено), seq 2218733674, win 29200, опции [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], длина 0
 00: 49: 33.247883 IP (tos 0xc0, ttl 64, id 9538, смещение 0, флаги [none], протокол ICMP (1), длина 88)
     10.0.2.1> 10.0.2.2: хост ICMP 173.194.219.100 недоступен - admin запрещен, длина 68
     IP (tos 0x0, ttl 63, id 46037, смещение 0, флаги [DF], протокол TCP (6), длина 60)
     10.0.2.2.48774> 173.194.219.100.443: флаги [S], cksum 0x47a7 (исправлено), seq 2218733674, win 29200, опции [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], длина 0
 00: 49: 33.253068 IP (tos 0x0, ttl 64, id 26282, смещение 0, флаги [DF], протокол TCP (6), длина 60)
     10.0.2.2.51312> 173.194.219.101.443: флаги [S], cksum 0x6ff8 (исправлено), seq 2634016105, win 29200, опции [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], длина 0
 00: 49: 33.254771 IP (tos 0xc0, ttl 64, id 9539, смещение 0, флаги [none], протокол ICMP (1), длина 88)
     10.0.2.1> 10.0.2.2: хост ICMP 173.194.219.101 недоступен - запрещено администратором, длина 68
     IP (tos 0x0, ttl 63, id 26282, смещение 0, флаги [DF], протокол TCP (6), длина 60)
     10.0.2.2.51312> 173.194.219.101.443: флаги [S], cksum 0x6ff8 (исправлено), seq 2634016105, win 29200, опции [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], длина 0
 00: 49: 33.258805 IP (tos 0x0, ttl 64, id 9293, смещение 0, флаги [DF], протокол TCP (6), длина 60)
     10.0.2.2.33686> 173.194.219.139.443: флаги [S], cksum 0x542b (исправлено), seq 995927943, win 29200, опции [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], длина 0
 00: 49: 33.258845 IP (tos 0xc0, ttl 64, id 9540, смещение 0, флаги [none], протокол ICMP (1), длина 88)
     10.0.2.1> 10.0.2.2: хост ICMP 173.194.219.139 недоступен - запрещено администратором, длина 68
     IP (tos 0x0, ttl 63, id 9293, смещение 0, флаги [DF], протокол TCP (6), длина 60)
     10.0.2.2.33686> 173.194.219.139.443: флаги [S], cksum 0x542b (исправлено), seq 995927943, win 29200, опции [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], длина 0
 ^ C
 13 захваченных пакетов
 13 пакетов, полученных фильтром
 0 пакетов, сброшенных ядром

Пакеты, захваченные с помощью tcpdump, предполагают попытку установить соединение (отправляются пакеты синхронизации), но ничего не получено. Также есть сообщение 10.0.2.1 > 10.0.2.2: ICMP host 173.194.219.139 unreachable - admin prohibited, length 68 что, кажется, предлагает проблему.

Любые предложения о том, как обойти эту проблему? Существуют ли правила iptable, которые необходимо добавить? Любые проблемы с брандмауэром (firewall-d?).


Примечание №1
Выход из 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
 [user @ local ~] $ sudo iptables-save
 # Сгенерировано iptables-save v1.4.21 в сб апр 15 01:40:57 2017
 * физ
 : ПРИНЯТИЕ ПРИНЯТИЯ [35: 8926]
 : INPUT ACCEPT [1:84]
 : OUTPUT ACCEPT [6: 439]
 : ПОСТРОЕНИЕ ПРИНИМАЕТ [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
 -А ПРЕРЫВАНИЕ -j PREROUTING_ZONES
 -A OUTPUT -j OUTPUT_direct
 -A POSTROUTING -j POSTROUTING_direct
 -A POSTROUTING -j POSTROUTING_ZONES_SOURCE
 -А ПОСТРОЕНИЕ -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
 COMMIT
 # Завершено в субботу 15 апреля 01:40:57 2017
 # Сгенерировано iptables-save v1.4.21 в сб апр 15 01:40:57 2017
 * калечить
 : ПРИНЯТИЕ ПРИНЯТИЯ [169: 18687]
 : INPUT ACCEPT [144: 11583]
 : FORWARD ACCEPT [0: 0]
 : OUTPUT ACCEPT [80: 8149]
 : ПОСТРОЕНИЕ ПРИНИМАЕТ [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
 -А ПРЕРЫВАНИЕ -j PREROUTING_ZONES
 -A INPUT -j INPUT_direct
 -В 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
 COMMIT
 # Завершено в субботу 15 апреля 01:40:57 2017
 # Сгенерировано iptables-save v1.4.21 в сб апр 15 01:40:57 2017
 *безопасность
 : 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
 -В FORWARD -j FORWARD_direct
 -A OUTPUT -j OUTPUT_direct
 COMMIT
 # Завершено в субботу 15 апреля 01:40:57 2017
 # Сгенерировано iptables-save v1.4.21 в сб апр 15 01:40:57 2017
 * сырье
 : ПРИНЯТИЕ ПРИНЯТИЯ [2362: 184437]
 : OUTPUT ACCEPT [1229: 185742]
 : OUTPUT_direct - [0: 0]
 : PREROUTING_direct - [0: 0]
 -A PREROUTING -j PREROUTING_direct
 -A OUTPUT -j OUTPUT_direct
 COMMIT
 # Завершено в субботу 15 апреля 01:40:57 2017
 # Сгенерировано iptables-save v1.4.21 в сб апр 15 01:40:57 2017
 *фильтр
 : 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 RELATED, ESTABLISHED -j ACCEPT
 -A INPUT -i lo -j ACCEPT
 -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 --reject-with icmp-host-forbidden
 -A FORWARD -m conntrack --ctstate RELATED, ESTABLISHED -j ACCEPT
 -A FORWARD -i lo -j ACCEPT
 -В 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 FORWARD -m conntrack -ctstate INVALID -j DROP
 -A FORWARD -j REJECT --reject-with icmp-host-forbidden
 -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 ACCEPT
 -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 ПРИНИМАЕТ
 -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
 COMMIT
 # Завершено в субботу 15 апреля 01:40:57 2017


Заметка 2:
Я устанавливаю веб-сервер apache на отдельный хост, к которому имеет доступ только локальный сервер. Я запустил tcpdump на веб-сервере, прослушивая порт 80. Когда я запускаю telnet webserver 80 я захватываю следующие пакеты. Это ожидаемое поведение, поскольку установлено TCP Connection (S, S-Ack, Ack).

 [user @ webserver ~] $ sudo tcpdump -nn -vv 'порт не 22 и 80' -i eth0 
 tcpdump: прослушивание eth0, link-type EN10MB (Ethernet), размер захвата 65535 байт
 07: 17: 30.411474 IP (tos 0x10, ttl 64, id 34376, смещение 0, флаги [DF], протокол TCP (6), длина 60)
     local.server.46710> web.server.80: Флаги [S], cksum 0x8412 (неверно -> 0x6d96), seq 3018586542, win 29200, опции [mss 1460, sackOK, TS val 3047398 ecr 0, nop, wscale 7] , длина 0
 07: 17: 30.411557 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], протокол TCP (6), длина 60)
     web.server.80> local.server.46710: флаги [S.], cksum 0x8412 (неправильные -> 0x9114), seq 2651711943, ack 3018586543, win 28960, опции [mss 1460, sackOK, TS val 37704524 ecr 3047398, nop , wscale 7], длина 0
 07: 17: 30.411725 IP (tos 0x10, ttl 64, id 34377, смещение 0, флаги [DF], протокол TCP (6), длина 52)
     local.server.46710> web.server.80: Флаги [.], cksum 0x840a (неверно -> 0x301c), seq 1, ack 1, win 229, options [nop, nop, TS val 3047398 ecr 37704524], длина 0

Когда я пытаюсь подключиться к веб-серверу с удаленного сервера через локальный сервер, tcpdump на веб-сервере не захватывает никаких пакетов (даже не начальную синхронизацию), но локальный сервер фиксирует пакет синхронизации, отправляемый на веб-сервер (см. Ниже). Это заставляет меня поверить, что что-то мешает отправке пакетов на веб-сервер – возможно, неправильная конфигурация или брандмауэр.

 [user @ local ~] $ sudo tcpdump -nn -vv 'порт не 22 и 80' -i любой
 tcpdump: прослушивание любого типа LINUX_SLL (Linux готово), размер захвата 65535 байт
 02: 24: 09.135842 IP (tos 0x10, ttl 64, id 38062, смещение 0, флаги [DF], протокол TCP (6), длина 60)
     10.0.2.2.50558> web.server.80: флаги [S], cksum 0x668d (исправлено), seq 69756226, win 29200, опции [mss 1460, sackOK, TS val 4780524 ecr 0, nop, wscale 7], длина 0

ВАЖНО: пакеты не маршрутизируются через eth0, но вместо этого делается попытка отправить пакеты на веб-сервер через tun0 (который не работает). Я могу подтвердить это, запустив tcpdump на интерфейсе tun0:

 [user @ local ~] $ sudo tcpdump -nn -vv 'порт не 22 и 80' -i tun0
 tcpdump: прослушивание на tun0, RAW канала (Raw IP), размер захвата 65535 байт
 02: 28: 10.295972 IP (tos 0x10, ttl 64, id 46976, смещение 0, флаги [DF], протокол TCP (6), длина 60)
     10.0.2.2.50560> webserver.80: Флаги [S], cksum 0xd560 (исправлено), seq 605366388, win 29200, опции [mss 1460, sackOK, TS val 5021684 ecr 0, nop, wscale 7], длина 0

Заметка 3:
Я отключил firewalld на локальном компьютере, и пакеты Sync были получены веб-сервером.

 [user @ local ~] $ sudo systemctl stop firewalld
 [user @ webserver ~] $ sudo tcpdump -nn -vv 'порт не 22 и 80' -i eth0
 tcpdump: прослушивание eth0, link-type EN10MB (Ethernet), размер захвата 65535 байт
 08: 25: 17.390912 IP (tos 0x10, ttl 63, id 61767, смещение 0, флаги [DF], протокол TCP (6), длина 60)
     10.0.2.2.50580> web.server.80: флаги [S], cksum 0x30dc (исправлено), seq 2601927549, win 29200, опции [mss 1460, sackOK, TS val 7123514 ecr 0, nop, wscale 7], длина 0
 08: 25: 17.391003 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], протокол TCP (6), длина 60)
     web.server.80> 10.0.2.2.50580: флаги [S.], cksum 0x4e23 (неверно -> 0xa316), seq 959115533, ack 2601927550, win 28960, опции [mss 1460, sackOK, TS val 41771503 ecr 7123514, nop , wscale 7], длина 0
 08: 25: 17.391192 IP (tos 0x0, ttl 128, id 60032, смещение 0, флаги [none], протокол TCP (6), длина 40)
     10.0.2.2.50580> web.server.80: Флаги [R], cksum 0x7339 (правильный), seq 2601927550, выигрыш 8192, длина 0
 08: 25: 18.393794 IP (tos 0x10, ttl 63, id 61768, offset 0, flags [DF], протокол TCP (6), длина 60)
     10.0.2.2.50580> web.server.80: Флаги [S], cksum 0x2cf1 (исправлено), seq 2601927549, win 29200, опции [mss 1460, sackOK, TS val 7124517 ecr 0, nop, wscale 7], длина 0
 08: 25: 18.393898 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], протокол TCP (6), длина 60)
     web.server.80> 10.0.2.2.50580: Флаги [S.], cksum 0x4e23 (неверно -> 0x7e71), seq 974785773, ack 2601927550, win 28960, опции [mss 1460, sackOK, TS val 41772506 ecr 7124517, nop , wscale 7], длина 0
 08: 25: 18.394003 IP (tos 0x0, ttl 128, id 60033, offset 0, флаги [none], протокол TCP (6), длина 40)
     10.0.2.2.50580> web.server.80: Флаги [R], cksum 0x566a (правильно), seq 2601927550, выигрыш 8192, длина 0

Теперь ясно, что исходный IP-адрес необходимо обновить, чтобы он соответствовал IP-адресу локального сервера, прежде чем пакет будет отправлен на веб-сервер. Как и предлагалось @xin, NAT необходимо настроить на локальном сервере.


Примечание №4:
Как только я попытаюсь подключиться к веб-серверу, я вижу, что счет pkts для правила 9 увеличивается на 1 (как видно ниже).

 [user @ local ~] $ sudo iptables -nvL -line-numbers
 ..........
 Цепочка FORWARD (политика ACCEPT 0 пакетов, 0 байт)
 num pkts bytes target prot opt ​​в исходном месте назначения         
 1 0 0 ACCEPT all - * * 0.0.0.0/0 0.0.0.0/0 ctstate СВЯЗАННЫЕ, УСТАНОВЛЕННЫЕ
 2 0 0 ACCEPT all - 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 all - * * 0.0.0.0/0 0.0.0.0/0           
 5 1 60 FORWARD_IN_ZONES all - * * 0.0.0.0/0 0.0.0.0/0           
 6 1 60 FORWARD_OUT_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0           
 7 1 60 FORWARD_OUT_ZONES all - * * 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 reject-with icmp-host-forbidden
 ..........
 [user @ local ~] $ sudo iptables -D FORWARD 9

Как только правило 9 из цепочки FORWARD будет удалено (сверху, как предлагается @xin), я могу подключиться к веб-серверу.

 [user @ local ~] $ sudo iptables -nvL -line-numbers
 ..........
 Цепь FORWARD (политика ACCEPT 1 пакет, 60 байт)
 num pkts bytes target prot opt ​​в исходном месте назначения         
 1 12 5857 ACCEPT all - * * 0.0.0.0/0 0.0.0.0/0 ctstate СВЯЗАННЫЕ, УСТАНОВЛЕННЫЕ
 2 0 0 ACCEPT all - 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 all - * * 0.0.0.0/0 0.0.0.0/0           
 5 2 120 FORWARD_IN_ZONES все - * * 0.0.0.0/0 0.0.0.0/0           
 6 2 120 FORWARD_OUT_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0           
 7 2 120 FORWARD_OUT_ZONES all - * * 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
 ..........

Исходный адрес пакетов должен быть заменен одним из адресов локальной машины, чтобы ответы могли быть получены локальным компьютером, в противном случае нет (хорошей) причины для отправки этих пакетов на следующие маршрутизаторы, ответ не может быть пойман в любом случае. iptables MASQUERADE и SNAT полезны для изменения адреса источника этих пакетов:

 [user@local ~]$ iptables -t nat -A POSTROUTING -s 10.0.2.2/32 ! -d 10.0.2.1/30 -j MASQUERADE -o eth0