Отправлять весь трафик на eth0, получать весь трафик на eth0, кроме доступа по ssh через eth1

Question

Я имею:

• интерфейс eth0 с 10.0.0.41 с публичным ip 54.xxx (будет использоваться для VPN-клиента)
• интерфейс eth1 с 10.0.0.100 с публичным ip 57.xxx

eth1 - это то, где я удаленно подключаюсь по SSH. eth0 будет подключаться к другому серверу как VPN IPsec.

потому что моя маршрутизация по умолчанию - eth1, при подключении к VPN она не срабатывает, потому что VPN-сервер разрешает только ip 54.xxx, а не трафик с 57.xxx

Теперь, как я могу указать маршрутизации, что весь трафик, идущий на адрес VPN-сервера: 212.xxx, будет отправляться через eth0 (54.xxx) и при этом иметь доступ к eth1 (57.xxx) для удаленного доступа по SSH?

РЕДАКТИРОВАТЬ:

РЕДАКТИРОВАТЬ: действительно ли amazon позволяет мне иметь 2 различных общедоступных IP-адреса подсети для моего 2-го сетевого интерфейса. похоже нет

РЕДАКТИРОВАТЬ: Amazon EC2 - VPC с несколькими подсетями

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenarios.html

Сценарий 1: VPC только с общедоступной подсетью - 1 подсеть http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario1.html

Сценарий 2: VPC с общедоступными и частными подсетями - 2 подсети http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html

Сценарий 3: VPC с общедоступными и частными подсетями и аппаратным VPN-доступом - 3 подсети http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario3.html

Сценарий 4: VPC только с частной подсетью и аппаратным VPN-доступом http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario4.html

РЕДАКТИРОВАТЬ:

Шаг 1: Amazon EC2> Сценарий 1: VPC только с общедоступной подсетью - 1 подсеть

Шаг 2: это позволит 10.0.0.0/24 подсети с 1: 1 NAT

Шаг 3: Теперь, чтобы сделать обход входящего и исходящего трафика, мы должны сделать:

ip rule add from 10.0.0.41/32 table 1 # outbound
ip rule add to 10.0.0.41/32 table 1   # inbound
ip route add default via 10.0.0.1 dev eth0 table 1

ip rule add from 10.0.0.100/32 table 2 # outbound
ip rule add to 10.0.0.100/32 table 2   # inbound
ip route add default via 10.0.0.1 dev eth1 table 2

Шаг 4: протестируйте его удаленно, предполагая, что удаленный компьютер имеет: iamremotely_publicip

ping publicip_eth0
ping publicip_eth1

Шаг 5: входящий тест

$ tcpdump -vv src iamremotely_publicip and not dst port 22 -i any

### inbound reply received for eth0
13:29:02.163426 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    2.205.81.5 > ip-10-0-0-41.eu-west-1.compute.internal: ICMP echo request, id 10242, seq 1, length 64

### inbound reply received for eth1
13:24:05.415740 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    2.205.81.5 > ip-10-0-0-100.eu-west-1.compute.internal: ICMP echo request, id 11808, seq 52, length 64

Шаг 6: исходящий тест на ПК iamremotely_publicip

$ tcpdump -vv src publicip_eth0 and not dst port 22 -i any
$ tcpdump -vv src publicip_eth1 and not dst port 22 -i any

Это работает без VPN.

Answer 1

Policyrouting должен работать с нормальной настройкой, не уверен, работает ли он с NAT/VPN, но я бы попробовал что-то в следующих строках:

ip rule add from src 10.0.0.41/32 table 1
ip route add default via 10.0.0.xxx dev eth0 table 1

ip rule add from src 10.0.0.100/32 table 2
ip route add default via 10.0.0.xxx dev eth1 table 2

но я понятия не имею, как Amazon маршрутизирует эти сети и будет ли VPN работать через эту настройку ..

Также вам может понадобиться сделать магию arp, чтобы заставить их работать должным образом, если кеш arp не холодный.

Но это должно гарантировать, что ваш трафик с 10.0.0.100 выходит через eth1 и .41 через eth0, чтобы вы могли иметь возможность получить к нему доступ через eth1, если его 1:1 NAT.

Не проверяйте это ни на чем, кроме тестового экземпляра, вы можете полностью потерять сетевое соединение.

Answer 2

Очень неясно, как настроена ваша локальная сеть, и кажется, что она отключена.

• что входит в eth0/1? DMZ-сервер? Или это маршрутизатор по умолчанию вашей локальной сети?

• Каковы фактические устройства, назначенные с 54.xxx и 57.xxx? Это 2 разных физических интернет-роутера? Или связь PPP установлена с этого хоста?

• Вы хотите, чтобы eth0 был выделенным интерфейсом для IPsec-связи с удаленной сетью, имеющей общедоступный IP-адрес 212.xxx, это правильно?

• Если eth0 предназначен для выделенного VPN-соединения с удаленной VPN-сетью, почему он вообще подключен к локальной подсети 10.0.0.x?

Вы должны использовать разные подсети для eth0 и eth1, иначе это очень сбивает с толку, и вы обязаны отправлять пакеты с обоих интерфейсов, потому что хост думает, что они находятся в одной подсети. Если eth0 предназначен только для выделенного VPN-канала, то для него указывается фиктивная подсеть, например 192.168.200.x. Ваша локальная и удаленная локальная сеть никогда не должна направляться в эту подсеть, они будут использовать эту ссылку только внутри туннеля VPN, который будет иметь локальные частные IP-адреса (10.0.0.x).

Пока у вас есть статический маршрут для 212.xxx для использования eth0, после установления VPN-канала весь трафик, предназначенный для удаленной ЛВС, будет использовать туннель и, следовательно, eth0, никакой специальной маршрутизации не требуется, пока Конечная точка IPsec существует на основном маршрутизаторе в вашей локальной сети, все необходимые маршруты должны быть настроены для вас.

Проблема, с которой вы сталкиваетесь с удаленным VPN-сервером, блокирующим 54.xxx, является ограничением безопасности исключительно для удаленного конца. Удаленный VPN-сервер ожидает трафик только от 57.xxx и блокирует запрос от 54.xxx Для чего вы должны выяснить, почему он это делает. Вы инициировали VPN-соединение, используя 57.xxx? Или VPN-сервер ограничивает доступ с помощью обратного просмотра DNS, и вы не настроили DNS должным образом, чтобы установить VPN-соединение с именем хоста DNS, которое разрешается обратно в 54.xxx? Связана ли ссылка IPsec с использованием сертификата SSL с именем хоста DNS, которое разрешается в 57.xxx?

РЕДАКТИРОВАТЬ: Вот пересмотренное предложение:

• Попросите Amazon предоставить другую подсеть по ссылке 54.xxx (вы не можете просто назначить произвольный IP на своем хосте и ожидать, что маршрутизаторы Amazon знают, как с этим справиться)

• Настройте eth0 с новой подсетью и шлюзом по умолчанию (скажем, ip 10.0.2.2 gw 10.0.2.1). 10.0.2.2 - это локальный IP для eth0, а 10.0.2.1 - это шлюз по умолчанию для этой подсети, который находится в сети Amazon.

• Ваш хост должен уже иметь маршрут по умолчанию для 10.0.2.0, чтобы использовать 10.0.2.2 в качестве интерфейса при настройке eth0, любой трафик для 10.0.2.0/24 будет пропускать eth1.

• настроить статический маршрут для VPN-сервера IP 212.xxx, чтобы использовать 10.0.2.1 в качестве шлюза. Не должно быть необходимости указывать eth0.

• СДЕЛАННЫЙ. Когда вы подключаетесь к 212.xxx, он автоматически использует eth0 и gw 10.0.2.1, который, в свою очередь, выходит в Интернет со ссылкой 54.xxx.