Это немного сложно, так что потерпите меня. У меня есть довольно хорошее практическое знание IP, но я ищу помощь в том, как это лучше всего реализовать.
Мой интернет-провайдер предоставил мне блок статических IP-адресов, а также один IP-адрес. В целях конфиденциальности вот схема сети, которую я буду использовать в своих примерах:
В этих примерах 172.16.0.1 и 172.16.1.1-5 на самом деле являются IP-адресами Интернета с глобальной маршрутизацией. Я использую частные IP-блоки в целях конфиденциальности. Итак, представьте, что 172.16.0.1 - это любой публичный IP-адрес, который вы хотите представить, и то же самое для блока 172.16.1.1.
Моя услуга предоставляется через интерфейс однокабельного модема с одним портом Ethernet. Другими словами, ожидается, что вся коммутация, маршрутизация и т. Д. Будет выполняться на стороне клиента.
В настоящее время у меня есть сервер Linux с двумя интерфейсами Ethernet. Ему назначается статический 172.16.0.1, и он использует NAT для предоставления Интернета в интерфейс LAN, который работает отлично. Я использовал эту настройку в течение многих лет, чтобы предоставить мне маршрутизатор NAT, который у меня гораздо более глубокий контроль, чем у стандартного маршрутизатора.
Теперь я хочу начать использовать те статические IP-адреса, которые у меня есть. Уловы такие:
Я все еще хочу иметь возможность, по крайней мере, до некоторой степени контролировать доступ к этим ящикам. Итак, в главном окне Linux я хотел бы сказать, что «172.16.1.1 не может принимать никакие входящие соединения, кроме порта 80» или «172.16.1.2 не может исходить ни к чему, кроме порта 22». Приведу несколько примеров. Другими словами, я все еще хочу, чтобы брандмауэр контролировал эти устройства. Подобно тому, как я могу сейчас использовать iptables
чтобы заблокировать, скажем, 192.168.1.5 от перехода куда-либо, кроме того, где я хочу, и в этом случае также подсчитывает входящие соединения. В идеале это означало бы, что я могу перенаправить все пакеты, предназначенные для одной из пяти общедоступных статик, через iptables и иметь такой же уровень контроля, как и над пакетами LAN.
Компьютерам в локальной сети (192.168.1.0/24) также может потребоваться доступ к этим общедоступным машинам. К тому же, компьютерам на общедоступной IPS может потребоваться доступ к компьютерам LAN. Итак, 172.16.1.2 может потребоваться доступ к 192.168.1.5 и наоборот.
Компьютеры, которые имеют статические IP-адреса с глобальной маршрутизацией, должны, если это вообще возможно, знать свой общедоступный IP-адрес. Одно из предложений, которое я видел для этого, предлагало подключать общедоступные компьютеры к локальной сети и давать им адреса локальной сети, а затем использовать множественную адресацию в системе Linux и перенаправлять все порты с желаемого статического на желаемый IP-адрес локальной сети. Это, безусловно, работает, но создает некоторые беспорядочные ситуации - теперь Linux-системе нужно знать каждый статический IP и, следовательно, это не будет хорошо масштабироваться. Так, например, "eth1" (интерфейс WAN) должен иметь не только уже используемый IP-адрес, но и все пять других IP-адресов. Это может быть хорошо для пяти, но как насчет масштабируемости, когда в будущем будет 2000 IP ...
Одна идея, которую я придумал, заключалась в добавлении третьего интерфейса к маршрутизатору Linux и настройке небольшой сети, содержащей только общедоступные машины. Единственный вопрос - это маршрутизация между этими машинами и Интернетом. Вдобавок ко всему, единственный простой способ, который я мог придумать, - это дать Linux-машине второй IP-адрес на eth2, что потребовало бы одной из этих пяти драгоценных статик.
Я не хочу использовать для этого какие-либо коммерческие решения. Я считаю, что Linux должен справиться с подобными ситуациями.
Я надеюсь, что эта схема сработает, но мне просто нужно выяснить, как выполнить маршрутизацию в Linux.
если вы добавите третий интерфейс, как указано выше, для создания DMZ, маршрутизация будет очень простой. буквально все, что вам нужно сделать, это включить IP Forwarding, и он будет пересылать пакеты между подключенными интерфейсами.
либо
sysctl -w net.ipv4.ip_forward=1
или
echo 1 > /proc/sys/net/ipv4/ip_forward
включить его на лету
или установить
net.ipv4.ip_forward=1
в /etc/sysctl.conf
Тогда вам просто понадобятся правила брандмауэра для управления доступом к компьютерам LAN из DMZ, вы все равно будете использовать NAT от интерфейса Wan к интерфейсу LAN, вы будете полагаться на правила Routing + доступа для управления из WAN в DMZ и DMZ. в LAN. Поскольку DMZ и GW по умолчанию для локальной сети являются одним и тем же блоком, вам не придется ретранслировать статические маршруты на компьютеры DMZ или LAN для доступа друг к другу. Другой вариант - разместить 2 карты Ethernet на каждом хосте DMZ и подключить их к локальной сети, но это не так чисто, как использование маршрутизатора посередине и списков доступа (iptables) для определения того, что может с чем разговаривать.
Я наконец понял это, и ради блага всех остальных стоит об этом написать здесь.
Я собираюсь получить коробку с тремя интерфейсами Ethernet. Вот как мы их подключаем:
Мы устанавливаем мост Linux с помощью bridge-utils (brctl), br0, который соединяет eth0 и eth1.
Затем мы можем дать интерфейсу br0 один из общедоступных IP-адресов. В конечном итоге это будет адрес, с которого будут приходить пакеты, приходящие с компьютеров LAN. В целях безопасности я буду использовать iptables для блокировки ВСЕГО трафика без NAT на этот IP:
iptables -A INPUT d 172.16.0.1 -j DROP
Это работает, поскольку трафик NAT будет передаваться по цепочке FORWARD, а незапрашиваемый Интернет-трафик будет появляться на INPUT.
Теперь на коммутаторе WAN я могу разместить другие хосты. Я перенесу свой основной сервер - веб-сервер и т. Д. - на этот коммутатор и статически назначу ему один из общедоступных IP-адресов с глобальной маршрутизацией.
Настоящая причина того, что это не было очевидным для меня раньше, заключалась в том, что я не думал, что могу использовать брандмауэр на интерфейсе моста - я не понимал, что пакеты моста действительно проходят через iptables. Оказывается, я не только могу это делать, но даже могу использовать такие приемы, как ulogd и подобные инструменты, для мониторинга пропускной способности и так далее. Ключ к этому - модуль iptables под названием physdev
, что позволяет вам использовать брандмауэр в зависимости от того, в какой физический интерфейс входит или выходит пакет, независимо от мостовой связи интерфейсов.
Поэтому я мог бы добавить правила брандмауэра в таблицу FORWARD, например:
iptables -A FORWARD -d 172.16.1.2 -p tcp --dport 80 -m physdev --physdev-in eth0 -j ACCEPT
iptables -A FORWARD -d 172.16.1.2 -m physdev --physdev-in eth0 -j DROP
Это приводит к тому, что из Интернета разрешается только трафик порта 80 на 172.16.1.2, даже если эта машина имеет общедоступный IP-адрес. (Помните, что в моих примерах 172.16.x.x общедоступны, хотя мы все знаем, что на самом деле это не так.)
Поскольку я использую physdev
, это означает, что машины в локальной сети могут по-прежнему иметь полный доступ к этому хосту. Так что со стороны LAN я все еще могу использовать SSH для 172.16.0.1. С точки зрения локальной сети, 172.16.0.1 вообще не имеет брандмауэра. То же самое с точки зрения другой машины DMZ. Однако с точки зрения Интернета 172.16.0.1 заблокирован.
Решение найдено! Это оказался действительно интересный проект.
F
Я полагаю, что функциональность, которую вы ищете, - это "сетевые псевдонимы". Затем вам нужно настроить «множественный NAT» для этих сетевых псевдонимов.
Я не знаю, что вы на самом деле используете на вашем Linux-маршрутизаторе, но если бы я мог предложить одно решение, просто установите "pfSense", который имеет множество функций ( http://www.pfsense.org/index.php@option=com_content&task=view&id=40&Itemid=43.html ) или IPCop ( http://www.ipcop.org/ ), то его гораздо проще администрировать, так как это графическое решение.
Это точно соответствует вашему варианту использования:
Более того, он работает на действительно старом оборудовании.
Янн