Я все еще немного смущен вашим описанием. Вот что я понял:
+--------------+ +---------+
| Ubuntu eth0 |----| Router/ |---- Internet
| | | Modem |
| | +---------|
| |
| | +---------+
| eth1 |----| Switch |---- LAN PC 1
| | | |
| | | |---- LAN PC 2
+--------------+ +---------+
Таким образом, ПК ПК 1, ПК ПК 2 и сервер Ubuntu должны иметь возможность общаться друг с другом (через eth1 на сервере Ubuntu), а сервер Ubuntu должен иметь доступ к Интернету, но ни ПК ПК 1, ни ПК ПК 2 должен иметь доступ к Интернету.
В этом случае вам просто нужно отключить пересылку на сервере Ubuntu (echo 0 > /proc/sys/net/ipv4/ip_forward
, хотя она отключена по умолчанию, или отредактировать /etc/sysctl.conf
чтобы сделать это при загрузке). Сервер будет связываться с Интернетом через eth0, а локальная сеть через eth1.
Если ситуация отличается, пожалуйста, отредактируйте свой вопрос, чтобы описать ситуацию.
Обратите внимание, что не "сетевые интерфейсы" (eth0, eth1) "обращаются" к чему-либо, а сами компьютеры. Может быть, это причина проблемы со связью.
редактировать
Да, вы можете выполнить свой сценарий в соответствии со своим чертежом, но это будет сложно: "Двойные" подключения к сети неинтересны.
Есть решение, которое намного проще, но вполне нормально, что другие локальные компьютеры теряют подключение к Интернету во время атаки: подключите все компьютеры к коммутатору и отсоедините кабель от коммутатора к маршрутизатору, когда вы что-то подозреваете. Все компьютеры сохраняют свои IP-адреса, вы можете ssh
с локального ПК на сервер, используя числовой адрес. (Или вы можете запустить DNS/DHCP с сервера вместо модема / маршрутизатора в первую очередь.)
Правильное решение для защиты вашего сервера и в то же время для того, чтобы ваши локальные ПК могли продолжать использовать Интернет, - это настроить брандмауэр (подойдет дешевый встроенный компьютер по крайней мере с двумя интерфейсами локальной сети) между модемом / маршрутизатором и сервером Ubuntu в DMZ с одной стороны и локальных ПК с другой. Если у вас есть полный доступ к вашему модему / маршрутизатору (например, с OpenWRT), этот межсетевой экран также может быть размещен там.
Теперь для вашего плана: не имеет значения, подключен ли сервер Ubuntu напрямую к маршрутизатору или к коммутатору: маршрутизатор имеет внутренний коммутатор, а каскадные коммутаторы ничего не меняют, все они считаются частью одной локальной сети сегмент.
Вот схема того, что вам нужно сделать. Это не проверено, и потребуется немного возиться, и могут быть ошибки, которые вообще не позволяют ему работать.
Предполагая, что маршрутизатор / модем работает на DHCP-сервере, убедитесь, что и eth0, и eth1 получают разные IP-адреса. Также убедитесь, что eth1 не получает маршрут по умолчанию. Для этого вам, возможно, придется изменить dhclient.conf
, возможно, написать разные строки request
для обоих интерфейсов.
Маршрутизация: eth0 должен получить маршрут по умолчанию. eth1 никогда не должен получать маршрут по умолчанию, даже если eth0 не работает. Возможно, вам придется бороться с установленными программами / скриптами, чтобы добиться этого. eth1 должен либо получить только локальный маршрут с более высокой метрикой (если это возможно), либо вообще не иметь маршрут (или подсеть / 1), когда eth0 работает, и локальный канал, когда eth0 не работает. Это означает, что вам, возможно, придется установить маршруты для eth1 в /etc/network/if-{up,down}
для eth0 (или каким-либо другим эквивалентом systemd в наши дни, если он вообще работает в systemd ...).
Причина: если и eth0, и eth1 имеют маршруты с одинаковой метрикой в локальной сети, пакеты будут отправляться случайным образом с обоих интерфейсов с разными IP-адресами источника. Для принимающей стороны в локальной сети это будет выглядеть так, как будто половина пакетов отброшена (потому что пакеты с правильным адресом источника никогда не поступают). Вот почему "двойной интерфейс" в одном и том же сегменте неинтересен.
- Вам нужны правила
iptables
которые блокируют все на eth1, кроме порта для ssh в локальную локальную сеть и из нее. Google для учебников.
Совсем немного работы.
редактировать
Более простой альтернативой является создание сетевого пространства имен (google для учебников), перемещение eth1 в это пространство имен, запуск внутри него sshd
и всех других служб вне пространства имен. Это означает, что оба интерфейса могут иметь маршруты по умолчанию и т.д., Только sshd проходит через eth1, а все остальные службы проходят через eth0. Для eth1 потребуется правило iptables
ограничивающее его локальной сетью при INPUT
и OUTPUT
.
редактировать
Как я уже сказал, удаленная отладка очень сложна (без обратной связи). Если вы не можете заставить его работать, задайте новый вопрос и опишите точно, что вы сделали (ip route
, ip addr
на всех соответствующих машинах, tcpdump
на соответствующих интерфейсах при выполнении ssh
и т.д.).
Я только что проверил; поскольку у меня нет двух Ethernet-интерфейсов, я использовал виртуальную этическую пару. Грубо говоря, создайте пространство имен и перенесите в него свой eth1
# ip netns add blue
# ip link set eth1 netns blue
Убедитесь, что он получает действительный адрес и маршрут, либо включив DHCP и убедившись, что он запущен, каким бы ни был метод вашей системы, либо установив его вручную (для тестирования), что-то вроде
# ip netns exec blue ip link set eth1 down
# ip netns exec blue ip addr add 192.168.4.1/24 dev eth1
# ip netns exec blue ip link set eth1 up
Вы должны получить адрес и маршрут, например (это было сделано с помощью виртуальной пары eth, поэтому она будет выглядеть не совсем так):
# ip ip netns exec blue ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether e6:5a:19:e0:63:75 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.44.1/24 scope global veth1b
valid_lft forever preferred_lft forever
inet6 fe80::e45a:19ff:fee0:6375/64 scope link
valid_lft forever preferred_lft forever
# ip netns exec blue ip route
192.168.44.0/24 dev eth1 proto kernel scope link src 192.168.44.1
Запустите sshd
в этом пространстве имен в другом xterm, добавьте отладочные флаги и используйте другой порт, чтобы избежать путаницы:
# ip netns exec blue /usr/sbin/sshd -D -d -p 222
Подключитесь к нему извне с помощью ssh 192.168.44.1 -p 222
, и это сработало хорошо: вы можете увидеть процесс подключения в сообщениях отладки.