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


9

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

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

[user @ remote ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state НЕИЗВЕСТНО 
    link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    инет 127.0.0.1/8 хост хоста lo
       valid_lft forever предпочитаемый_lft forever
    inet6 :: хозяин области видимости 1/128 
       valid_lft forever предпочитаемый_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast состояние UP qlen 1000
    ссылка / эфир AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
    инет AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 охват глобальная динамическая eth0
       valid_lft 1785sec предпочитаемый_lft 1785sec
    inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 глобальная динамическая область действия noprefixroute 
       valid_lft 2591987sec предпочитаемый_lft 604787sec
    inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 ссылка области 
       valid_lft forever предпочитаемый_lft forever
[user @ local ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state НЕИЗВЕСТНО 
    link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    инет 127.0.0.1/8 хост хоста lo
       valid_lft forever предпочитаемый_lft forever
    inet6 :: хозяин области видимости 1/128 
       valid_lft forever предпочитаемый_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast состояние UP qlen 1000
    ссылка / эфир AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
    инет AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 охват глобальная динамическая eth0
       valid_lft 1785sec предпочитаемый_lft 1785sec
    inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 глобальная динамическая область действия noprefixroute 
       valid_lft 2591987sec предпочитаемый_lft 604787sec
    inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 ссылка области 
       valid_lft forever предпочитаемый_lft forever

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

[user @ remote ~] $ sudo ip tuntap добавить режим tun0 tun
[user @ remote ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state НЕИЗВЕСТНО 
    link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    инет 127.0.0.1/8 хост хоста lo
       valid_lft forever предпочитаемый_lft forever
    inet6 :: хозяин области видимости 1/128 
       valid_lft forever предпочитаемый_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast состояние UP qlen 1000
    ссылка / эфир AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
    инет AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 охват глобальная динамическая eth0
       valid_lft 1785sec предпочитаемый_lft 1785sec
    inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 глобальная динамическая область действия noprefixroute 
       valid_lft 2591987sec предпочитаемый_lft 604787sec
    inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 ссылка области 
       valid_lft forever предпочитаемый_lft forever
3: tun0: mtu 1500 состояние ndisc noop ВНИЗ qlen 500
    не ссылка / нет 

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

[user @ local ~] $ sudo ip tuntap добавить режим tun0 tun
[user @ local ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state НЕИЗВЕСТНО 
    link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
    инет 127.0.0.1/8 хост хоста lo
       valid_lft forever предпочитаемый_lft forever
    inet6 :: хозяин области видимости 1/128 
       valid_lft forever предпочитаемый_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast состояние UP qlen 1000
    ссылка / эфир AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
    инет AAA.BBB.CCC.DDD / 24 brd AAA.BBB.CCC.255 охват глобальная динамическая eth0
       valid_lft 1785sec предпочитаемый_lft 1785sec
    inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: LLLL / 64 глобальная динамическая область действия noprefixroute 
       valid_lft 2591987sec предпочитаемый_lft 604787sec
    inet6 ABCD :: IIII: JJJJ: KKKK: LLLL / 64 ссылка области 
       valid_lft forever предпочитаемый_lft forever
3: tun0: mtu 1500 состояние ndisc noop ВНИЗ qlen 500
    не ссылка / нет

Назначьте IP-адрес для tun0 и вызовите его:

[user @ local ~] $ sudo ip addr add 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 состояние ВНИЗ qlen 500
    не ссылка / нет 
    Inet 10.0.2.1/30 глобальный объем Tun0
       valid_lft forever предпочитаемый_lft forever
[user @ remote ~] $ sudo ip addr add 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 состояние ВНИЗ qlen 500
    не ссылка / нет 
    inet 10.0.2.2/30 scope global tun0
       valid_lft forever предпочитаемый_lft forever

Измените 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? Сс 23:12 0:00 сш -f -w0: 0 root @ remote true

Проверьте пинг на обоих серверах, используя новые 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 статистика пинга ---
2 переданных пакета, 2 полученных, потеря пакета 0%, время 1002 мс
rtt мин / среднее / макс / mdev = 0,861 / 1,274 / 1,668 / 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 пинг статистика ---
2 пакета передано, 2 получено, потеря пакета 0%, время 1000 мс
rtt мин / среднее / макс / mdev = 0,589 / 0,739 / 0,889 / 0,150 мс
[user @ remote ~] $ route
Таблица маршрутизации IP ядра
Шлюз назначения Genmask Флаги Метрика Ссылка Использовать 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 протостатическая метрика 100 
10.0.2.0/30 dev tun0 Proto: ядро, ссылка src 10.0.2.2. 
AAA.BBB.CCC.0 / 24 dev eth0 протокольная область видимости ссылка 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 add 173.194.219.0/24 dev tun0
[user @ remote ~] $ route
Таблица маршрутизации IP ядра
Шлюз назначения Genmask Флаги Метрика Ссылка Использовать 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 протостатическая метрика 100 
10.0.2.0/30 dev tun0 Proto: ядро, ссылка src 10.0.2.2. 
AAA.BBB.CCC.0 / 24 dev eth0 протокольная область видимости ссылка 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
сокет: нет маршрута к хосту
подключения: ERRNO = 113

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

    10.0.2.2.52768> 173.194.219.102.443: Флаги [S], cksum 0x8702 (правильно), seq 994650730, выигрыш 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, выигрыш 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, флаги [нет], протокол ICMP (1), длина 88)
    10.0.2.1> 10.0.2.2: узел ICMP 173.194.219.100 недоступен - администратор запрещен, длина 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, выигрыш 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, выигрыш 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, флаги [нет], протокол 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, выигрыш 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, выигрыш 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, флаги [нет], протокол 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, выигрыш 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которое, кажется, предлагает проблему.

Любые предложения о том, как обойти эту проблему? Есть ли приемлемые правила, которые нужно добавить? Любые проблемы с брандмауэром (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]
: ВВОД ПРИНЯТЬ [1:84]
: ВЫХОД ПРИНЯТ [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
-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
-А РАЗМЕЩЕНИЕ -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]
: ВВОД ПРИНЯТЬ [144: 11583]
: ВПЕРЕД ПРИНЯТЬ [0: 0]
: ВЫХОД ПРИНЯТ [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
-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
COMMIT
# Завершено в субботу 15 апреля 01:40:57 2017
# Генерируется iptables-save v1.4.21 в субботу 15 апреля 01:40:57 2017
*безопасность
: ВВОД ПРИНЯТЬ [2197: 163931]
: ВПЕРЕД ПРИНЯТЬ [0: 0]
: ВЫХОД ПРИНЯТ [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
COMMIT
# Завершено в субботу 15 апреля 01:40:57 2017
# Генерируется iptables-save v1.4.21 в субботу 15 апреля 01:40:57 2017
* сырье
: ПРЕДВАРИТЕЛЬНЫЙ ПРИНЯТ [2362: 184437]
: ВЫХОД ПРИНЯТ [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
*фильтр
: ВВОД ПРИНЯТЬ [0: 0]
: ВПЕРЕД ПРИНЯТЬ [0: 0]
: ВЫХОД ПРИНЯТ [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 СВЯЗАННЫЕ, УСТАНОВЛЕННЫЕ -j ПРИНЯТЬ
-A ВВОД -i lo -j ПРИНЯТЬ
-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-запрещено
-A ВПЕРЕД -m conntrack --ctstate СВЯЗАННЫЕ, УСТАНОВЛЕННЫЕ -j ПРИНЯТЬ
-A ВПЕРЕД -i lo -j ПРИНЯТЬ
-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 FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-запрещено
-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 ПРИНЯТЬ
-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 НОВОЕ -j ПРИНЯТЬ
COMMIT
# Завершено в субботу 15 апреля 01:40:57 2017


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

[user @ webserver ~] $ sudo tcpdump -nn -vv 'порт не 22 и 80' -i eth0 
tcpdump: прослушивание по eth0, тип канала 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: Flags [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, смещение 0, флаги [DF], протокол TCP (6), длина 60)
    web. , шкала 7], длина 0
07: 17: 30.411725 IP (tos 0x10, ttl 64, id 34377, смещение 0, флаги [DF], протокол TCP (6), длина 52)
    local.server.46710> web.server.80: Flags [.], cksum 0x840a (неверно -> 0x301c), seq 1, ack 1, win 229, опции [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: Flags [S], cksum 0xd560 (правильно), seq 605366388, win 29200, опции [mss 1460, sackOK, TS val 5021684 ecr 0, nop, wscale 7], длина 0


Примечание № 3:
Я выключил firewalld на локальном компьютере, и веб-сервер получил пакеты синхронизации.

[user @ local ~] $ sudo systemctl stop firewalld
[user @ webserver ~] $ sudo tcpdump -nn -vv 'порт не 22 и 80' -i eth0
tcpdump: прослушивание по eth0, тип канала 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, смещение 0, флаги [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 , шкала 7], длина 0
08: 25: 17.391192 IP (tos 0x0, ttl 128, id 60032, смещение 0, флаги [нет], протокол 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, смещение 0, флаги [DF], протокол TCP (6), длина 60)
    10.0.2.2.50580> web.server.80: Flags [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, смещение 0, флаги [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 , шкала 7], длина 0
08: 25: 18.394003 IP (tos 0x0, ttl 128, id 60033, смещение 0, флаги [нет], протокол 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 ​​in out source source         
1 0 0 ПРИНЯТЬ все - * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED, ESTABLISHED
2 0 0 ПРИНЯТЬ все - 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 все - * * 0.0.0.0/0 0.0.0.0/0           
5 1 60 FORWARD_IN_ZONES все - * * 0.0.0.0/0 0.0.0.0/0           
6 1 60 FORWARD_OUT_ZONES_SOURCE все - * * 0.0.0.0/0 0.0.0.0/0           
7 1 60 FORWARD_OUT_ZONES все - * * 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-запрещено
..........
[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 ​​in out source source         
1 12 5857 ПРИНЯТЬ все - * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED, ESTABLISHED
2 0 0 ПРИНЯТЬ все - 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 все - * * 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 все - * * 0.0.0.0/0 0.0.0.0/0           
7 2 120 FORWARD_OUT_ZONES все - * * 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
..........

Ответы:


4

Исходный адрес пакетов должен быть заменен одним из адресов локальной машины, чтобы ответы могли быть получены на локальной машине, в противном случае (хорошая) причина для отправки этих пакетов на следующие маршрутизаторы не может быть перехвачена. 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

Спасибо за ответ @xin. Я выполнил указанную вами команду, но получил тот же ответ. Я запустил tcpdump на eth0 и tun0. пакеты не маршрутизируются на eth0. tun0 все еще пытается связаться с Google. Нужно ли как-то маршрутизировать пакеты от tun0 до eth0?
Али

1
Если локальный компьютер использует интерфейс eth0 для подключения к Интернету, пакеты должны идти к eth0 даже без этой команды. Так что, возможно, некоторые настройки брандмауэра участвуют. Можете ли вы поставить iptables-saveвывод локальной машины?
Reith

Я добавил вывод iptables-save к исходному сообщению.
Али

Firewalld нужно было выключить. Я запустил вашу команду после выключения firewalld, и соединение начало работать! Ценю твою помощь! Оформить заметки в оригинальном сообщении, чтобы увидеть прогресс.
Али

1
отличная работа. Похоже, проблема является приемлемым правилом -A FORWARD -j REJECT --reject-with icmp-host-prohibited. пакеты, поступающие на ваш компьютер и имеющие адрес получателя, будут отправляться в цепочку FORWARD, поэтому отбросьте это правило.
Reith
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.