Добрый день. Подскажите как грамотно пробрасывать портs в iptables? сейчас делаю так:
iptables -t nat -A PREROUTING -i $EXT_INT -p tcp --dport $EXT_PORT -j DNAT --to-destination $DEST:$PORT
$EXT_INT - внешний интерфейс.
$EXT_PORT - внешний порт
$DEST:$PORT - ip машины назначения с портом.
Все хорошо, с внешки я обратиться к порту могу. А вот изнутри сети, указывая свой внешний адрес чтобы проверить - не могу. Всякие CMS для камер и даже тот же openvpn пытаются подключиться, но все обламываются. Openvpn пишет сначала connection established и сразу же connection refused. С простыми маршрутизаторами если делаю просто проброс - это прокатывает. Видимо что-то в правилах iptables я еще должен указать?
upd: Если я вдруг неясно выяснился: в качестве маршрутизатора у меня машина с линуксом.
У вас на шлюзе уже есть маскарадинг/SNAT пакетов, которые уходят во внешнюю сеть, поэтому тут все ок. А для пакетов, которые уйдут во внутреннюю - нет. Поэтомуу и получается, что пакет уходит до севера назначения, но sourceIP у него из той же подсети. Сервер отвечает ему напрямую, а не через роутер. И клиент получает ответ с адресом источника из внутр. сети, вместо EXT_ADDR (куда он его посылал) и отбрасывает такой пакет.
раз ты теперь увидел картинку с сутью проблемы по ссылке, разверну мысль. вообще hairpin nat не лучший вариант. иногда без него правда никак, но это что-то вроде подвешивания патчика соплей между свитчами. чаще всего если ты его юзаешь - значит в сети что-то не так.
например для CMS/почтовика проблема чаще всего решается локальным DNS. просто для сервера - разбивкой vlan. hairpin nat подходит хорошо разве что у тебя малина на локалхосте файл-сервером подрабатывает. короче видя суть проблемы попытайся подумать как ее лучше всего обойти в условиях твоей сети
Да мне в принципе эта штука нужна не для работы, а просто для проверки внутренних сервисов
суть поста была слегка не в том. я имел ввиду что основная фишка это сама проблема, которая очень неплохо описана по ссылке которую ты нашел. а как ее решать - ну, зависит от инфраструктуры. в целом можно и через hairpin nat
Интересно было б послушать набор альтернативных решений, не указанных в статье
уже привел - третий пост вверх от того на который ссылка. самое простое - локальный DNS если нужно с CMS/почтой работать. если машины в разных вланах и коммутация идет через L3-свитч - можно на нем сделать аналогичный нат при условии что это не ломает структуру. можно вообще попрыгать с двухуровневой сетью на манер SDN. можно (но не нужно) с vpn извратиться. вариантов много. можно вообще спросить себя «нахрена я обращаюсь по внешнему адресу? нельзя ли обращаться по внутреннему?» и это может вылиться в перенастройку, скажем, nginx'а.
А, ну я собственно под статьёй эту ссылку и понимал. Там собственно и была эта самая одна альтернатива с split dns. С VPN явно не то, ведь это же и так одна локалка, куда туннелировать то?
С VPN явно не то, ведь это же и так одна локалка, куда туннелировать то?
потому и написал можно, но не нужно. внутри локалки тоже можно поднять впн, особенно если выкинуть сервак в немаршрутизируемый влан. но этого делать правда не следует. самое логичное, как уже написал выше, DNS либо любая другая управляемая прослойка. все от масштабов сети зависит. вдруг ТС может у себя поднять внутри локалки ebgp, мало ли
а, не, что-то походу пора чай пить идти. vpn действительно позволит пустить весь поток через роутер, но нат так или иначе будет нужен
Меня всегда интересовал вопрос, можно ли наколхозить схему: в локалке помимо маршрутизатора есть сервер и пользователи. Каких-либо специальных настроек у них кроме маршрутизатора — нет. Но сервер, не догадываясь, что это фикция (по адресу провайдера не внешний маршрутизатор, а свой) «имеет» и интерфейс с белым адресом помимо интерфейса в локалке. Тогда нет проблем внутри локалки по какому адресу обращаться к серверу - по белому или серому, серверу не надо косвенным способом узнавать какой клиент внутри локалки обратился, так как адреса не натятся, сервисы на сервере про NAT тоже не в курсе и работают с миром, скажем с email как настроящие, не волнуясь о маскарадинге адреса в ответе, там так и будет hello/outgoing в тексте email-протокола всё «настоящее», что никакой NAT всё равно не умеет. В качестве default gw прописан адрес провайдера, а вот уже со своим gw веселуха и начинается... Одно решение я знаю - прозрачный маршрутизатор без адреса, но там проблема, нельзя повесить на такой маршрутизатор сервис, все сервисы придётся ставить на сервер.
Купите у провайдера routed subnet, что же вы так мучаетесь? Например, у меня почтовый сервер стоит за моим маршрутизатором в DMZ и имеет публичный IP, скажем, 1.2.3.2/30. В локальную сеть он вообще не подключен. Отдельный интерфейс моего маршрутизатора, который смотрит в почтовик - аналогично, имеет белый IP 1.2.3.1 из той же подсети. Провайдер настраивает у себя маршруты так, чтобы все, что летит в эту 1.2.3.0/30 routed subnet отправлялось на мой маршрутизатор. Ни NAT, ни NAT-reflection, ни split horizon DNS - ничего нету. Плюс безопасность - почтовик не может инициировать соединение в локалку, это запрещено на маршрутизаторе.
Не, не, интересует только конкретная задача, как изложено в упрощённом виде, так как на самом деле чтобы описать реальную задачу целую статью писать. Там и резервирование (наличествует), и спец железки и проблема с mtu, всё это в филиалах, в центре такой проблемы нет... И ещё вагон и маленькая тележка.
в данном случае - известен. но я что-то читаю про SNAT - в основном пишут что он нужен когда у меня несколько внешних адресов. Можно ссылку на ман, который поможет в моем вопросе? Необязательно на русском.
