Два сетевых адаптера, один со статическим ip и один DHCP. Политика IP-маршрутизации

У меня проблемы с настройкой принадлежащего мне сервера. Он имеет Linux Ubuntu Server Edition 10.04 LTS в качестве ОС, две сетевые карты (eth0 и eth1) и использует OpenVPN.

eth0 подключен к коммутатору, который подключен к 3G-маршрутизатору (статический IP-адрес: 192.168.0.254), а eth1 иногда подключается к неизвестной (до этого) неизвестной локальной сети и использует DHCP для получения IP-адреса. Только один из этих интерфейсов будет иметь доступ к Интернету одновременно, т. Е. Если кабель подключен к eth1, необходимо, чтобы маршрутизатор 3G был выключен *.

В конечном счете, я хотел бы, чтобы весь трафик проходил через VPN с использованием интерфейса, подключенного к Интернету, а также весь трафик на определенный IP-адрес и порт (скажем, 192.168.45.1:8443) для использования eth1, несмотря ни на что.

В процессе настройки я сначала сосредоточился на части 3G, оставил eth1 отключенным и смог использовать VPN для связи с другими серверами в VPN через eth0.

/ etc / network / interfaces выглядит следующим образом:

auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.254

auto eth1
iface eth1 inet dhcp

Затем я подключил Ethernet-кабель к Eth1, отключил VPN и выключил 3G-маршрутизатор. Локальная сеть, к которой подключен eth1, имеет сервер DHCP (192.168.0.254) и имеет тот же диапазон ip, что и машины, подключенные к eth0 (192.168.0.x). Я ни в коем случае не могу гарантировать, что обе подсети будут разными в будущем.

Сервер получает IP-адрес (192.168.0.45) от DHCP-сервера, но я не могу ни пропинговать его, ни увидеть сервер в списке подключенных устройств на интерфейсе DHCP-сервера.

Закомментировав строку шлюза в /etc/network/interfaces, я могу проверить связь с DHCP-сервером так же, как и с любым другим сервером в локальной сети, но все же не наоборот. Кроме того, это работает, только если я укажу интерфейс для пинга:

• пинг 192.168.0.254

  PING 192.168.0.254 (192.168.0.254) 56(84) bytes of data.
  From 192.168.0.100 icmp_seq=1 Destination Host Unreachable
  From 192.168.0.100 icmp_seq=3 Destination Host Unreachable
  From 192.168.0.100 icmp_seq=4 Destination Host Unreachable
  ^C
  --- 192.168.0.254 ping statistics ---
  6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5007ms, pipe 3
  

• ping 192.168.0.254 -I eth1

  PING 192.168.0.254 (192.168.0.254) from 192.168.0.100 eth1: 56(84) bytes of data.
  64 bytes from 192.168.0.254: icmp_seq=1 ttl=255 time=0.738 ms
  64 bytes from 192.168.0.254: icmp_seq=2 ttl=255 time=0.832 ms
  64 bytes from 192.168.0.254: icmp_seq=3 ttl=255 time=0.809 ms
  64 bytes from 192.168.0.254: icmp_seq=4 ttl=255 time=0.795 ms
  
  --- 192.168.0.254 ping statistics ---
  4 packets transmitted, 4 received, 0% packet loss, time 2997ms
  rtt min/avg/max/mdev = 0.738/0.793/0.832/0.044 ms
  

Я понятия не имею, почему это все еще говорит from 192.168.0.100 даже при пинге по eth1, так как это не его адрес.

Я читал о IP Policy Routing, и мне показалось, что именно так я и должен идти, чтобы в конечном итоге достичь того, чего я хочу (среди прочего, форсировать трафик к определенному ip / порту и через eth1). Если я правильно понимаю, что может сделать невозможным пинговать сервер с любой другой машины в локальной сети, это то, что он возвращает весь трафик через eth0, если это маршрут по умолчанию?

Тем не менее, глядя на вывод route мне кажется, что маршрут по умолчанию на eth1?

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth1
default         192.168.0.254   0.0.0.0         UG    100    0        0 eth1

Я прочитал этот пост и связанный с ним пост и попытался адаптировать его, чтобы заставить весь трафик, который идет в eth0, выходить из eth0 и то же самое для eth1:

ip route add default dev eth0 table 3G
ip route add default dev eth1 table LAN
ip rule add fwmark 0x1 table 3G
ip rule add fwmark 0x2 table LAN
iptables -A OUTPUT -t mangle -o eth0 -j MARK --set-mark 1
iptables -A OUTPUT -t mangle -o eth1 -j MARK --set-mark 2

Но это не работает, и после этого я больше не могу пинговать DHCP-сервер. Думаю, я неправильно понял, как это работает...

Что я должен делать?

Кроме того, я пока оставил часть VPN, но немного обеспокоен тем, что она не будет работать так, как я искренне ожидал. Как взаимодействуют маршруты и VPN? Я должен быть уверен, что маршрут, который заставляет весь трафик к и от определенного ip / маршрута через eth1, не может быть решен, если eth1 не связан.

Заранее большое спасибо за вашу помощь. Я был бы очень рад предоставить любую другую информацию, если это необходимо. Пожалуйста, извините, если на этот вопрос уже был дан ответ где-то еще, я не нашел его (или если он слишком простой).

* было бы еще лучше, если бы я мог настроить, чтобы весь трафик, кроме и с подмножества IP-адресов, проходил через eth1, если подключен кабель.

Edit>

eth0 теперь находится в подсети 10.13.37.0/255.255.255.248, а сервер имеет 10.13.37.2 в качестве ip.

Весь трафик теперь проходит через VPN, но я бы хотел, чтобы этот трафик проходил до 192.168.45.1 (192.168.45.0/24 - это подсеть OpenVPN) на порту 443, хотя он все еще использует транспортировку через VPN, использует только eth1 (таким образом, делая его недоступным, если нет соединение существует) и трафик к 192.168.45.1 через порт 8443 использует только eth0. Это возможно?

ip route add default dev eth0 table 3G
ip route add default dev eth1 table LAN
ip rule add fwmark 0x1 table 3G
ip rule add fwmark 0x2 table LAN
iptables -A OUTPUT -t mangle -o eth0 --dst 192.168.45.1 --dport 8443 -j MARK --set-mark 1
iptables -A OUTPUT -t mangle -o eth1 --dst 192.168.45.1 --dport 443 -j MARK --set-mark 2

но, используя iptraf, я могу видеть, что когда wgeting что-то на 443 или 8443, используется только eth1.

Спасибо!