У меня проблемы с настройкой принадлежащего мне сервера. Он имеет 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
пинг 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-политик, и мне показалось, что это именно тот путь, которым я должен следовать, чтобы в конечном итоге достичь того, чего я хочу (среди прочего, форсирование трафика на определенный 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, если подключен кабель.
Редактировать>
eth0 теперь находится в подсети 10.13.37.0/255.255.255.248, а IP-адрес сервера - 10.13.37.2.
Весь трафик теперь проходит через 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, я вижу, что при получении чего-либо на 443 или 8443 используется только eth1.
Спасибо!
Вы уверены, что подключили нужный кабель? похоже, что вы подключаете кабель локальной сети 192.168.0.x к eth1, а не к eth0.
если это не так, пытались ли вы отсоединить ОБЕИХ кабеля и выполнить эхо-запрос только с одним подключенным кабелем? Подобно:
Кстати, ИЗМЕНИТЕ ОДНУ НАСТРОЙКУ LAN! Если вы не можете изменить конфигурацию eth1 lan, измените eth0 с маршрутизатором 3G с 192.168.0.x на 192.168.1.x (для всех компьютеров в этой локальной сети), иначе у вас ВСЕГДА будут ПРОБЛЕМЫ с тем же ip lan.