Перейти к содержимому
Калькуляторы

Не работает НАТ

Всем привет. Собственно вопрос вот в чем,

есть: сервер на нем все, биллинг, нат, пптпд

делаю: делю на отдельно сервер с биллингом, отдельно нат с пптпд (аксель)

сделал дубли правил с работающего сервера, правила ната, правила форвардинга. Клиент подключается, но интернета нет (пинги не ходят, ничего не работает, днс резолвится норм)

при этом люди что имеют реальный ип, выходят в сеть нормально. Еще момент есть, судя по биллинг (УТМ) есть клиенты которые и с серыми ИП были в интернете (трафик капал на них)

 

Что я делаю не так?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Первое что приходит в голову - это посмотреть iptables -nL и iptables -nL -t nat (запросто могли не включить поддержку NAT в ядре или не подгрузить модуль iptables).

 

Второе - это посмотреть какие серые ip выдаются клиентам при подключении к серверу и правильно ли выдается ip (соотвественно ip-up, ip-down надо глядеть).

 

Третье - сделать как минимум traceroute от клиента до сервера, до днс, до внешнего шлюза, до любого адреса в инете.

 

Четвертое - самому прикинуться клиентом и посмотреть на ситуацию с точки зрения клиента, а не только по показаниям сервера.

--------

Ждать, когда закапает трафик и ориентироваться только по этому - ошибка. Трафик вообще не показатель что все работает.

 

Реальники работают очевидно потому что они не натятся, а форвардятся.

Изменено пользователем replicant

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

адреса выдаюся биллингом (к каждому абону свой ип привязан, статика)

адреса типо

192.168.0-10.хх/32

 

пробовал форвардинг разрешать для всех, все равно

# iptables -nL

Chain INPUT (policy ACCEPT)

target prot opt source destination

 

Chain FORWARD (policy DROP)

target prot opt source destination

tcp -- 192.168.0.0/16 0.0.0.0/0 tcp dpt:25 state NEW recent: SET name: SMTP side: source

REJECT tcp -- 192.168.0.0/16 0.0.0.0/0 tcp dpt:25 state NEW recent: UPDATE seconds: 60 hit_count: 5 name: SMTP side: source reject-with icmp-port-unreachable

ACCEPT all -- xxx.xxx.xx.3 0.0.0.0/0

ACCEPT all -- 0.0.0.0/0 xxx.xxx.xx.3

ACCEPT all -- xxx.xxx.xx.2 0.0.0.0/0

ACCEPT all -- xxx.xxx.xx.5 0.0.0.0/0

ACCEPT all -- xxx.xxx.xx.1 0.0.0.0/0

ACCEPT all -- 0.0.0.0/0 xxx.xxx.xx.2

ACCEPT all -- 0.0.0.0/0 xxx.xxx.xx.5

ACCEPT all -- 0.0.0.0/0 xxx.xxx.xx.1

ACCEPT all -- 192.168.1.5 0.0.0.0/0

ACCEPT all -- 192.168.1.7 0.0.0.0/0

ACCEPT all -- 192.168.1.8 0.0.0.0/0

.....

 

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

iptables -nL -t nat

Chain PREROUTING (policy ACCEPT)

target prot opt source destination

 

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

SNAT all -- 192.168.0.0/16 0.0.0.0/0 to:хх.хх.хх.122

 

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

пробовал быть клиентом, все заканчивается на сервере.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Попробуйте такое правило вместо того, что есть сейчас

 

iptables -t nat -A POSTROUTING -s 192.168.0.0/16 ! -d 192.168.0.0/16 -j SNAT --to-source ВНЕШНИЙ IP СЕРВАКА

 

ipv4_forward в sysctl включено (хотя, если реальники работают, то должно быть включено)?

Изменено пользователем replicant

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

странно все это, потому как все эти правила скопировал с работающего сервера...

может есть какие то различия (на рабочем стоит мандрива, а тут центос)

 

sysctl -a | grep forward

net.ipv6.conf.eth0.forwarding = 0

net.ipv6.conf.default.forwarding = 0

net.ipv6.conf.all.forwarding = 0

net.ipv6.conf.lo.forwarding = 0

net.ipv4.conf.eth0.mc_forwarding = 0

net.ipv4.conf.eth0.forwarding = 1

net.ipv4.conf.eth1.mc_forwarding = 0

net.ipv4.conf.eth1.forwarding = 1

net.ipv4.conf.lo.mc_forwarding = 0

net.ipv4.conf.lo.forwarding = 1

net.ipv4.conf.default.mc_forwarding = 0

net.ipv4.conf.default.forwarding = 1

net.ipv4.conf.all.mc_forwarding = 0

net.ipv4.conf.all.forwarding = 1

net.ipv4.ip_forward = 1

Изменено пользователем Cramac

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Внутренний IP сервера не попадает в диапазон адресов, который выдает биллинг клиентам pptp?

Как выглядит при этом ipconfig /all на клиенте, когда тот подключен к серверу на примере windows клиента?

Изменено пользователем replicant

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

>ipconfig /all

 

Настройка протокола IP для Windows

 

Имя компьютера . . . . . . . . . : q632112387

Основной DNS-суффикс . . . . . . :

Тип узла. . . . . . . . . . . . . : неизвестный

IP-маршрутизация включена . . . . : нет

WINS-прокси включен . . . . . . . : нет

 

Подключение по локальной сети - Ethernet адаптер:

 

DNS-суффикс этого подключения . . :

Описание . . . . . . . . . . . . : 3Com 3C940 Gigabit LOM Ethernet Adap

ter

Физический адрес. . . . . . . . . : 00-0C-6E-BD-52-9F

Dhcp включен. . . . . . . . . . . : нет

IP-адрес . . . . . . . . . . . . : 10.10.10.33

Маска подсети . . . . . . . . . . : 255.255.255.0

Основной шлюз . . . . . . . . . . : 10.10.10.254

 

Интернет - PPP адаптер:

 

DNS-суффикс этого подключения . . :

Описание . . . . . . . . . . . . : WAN (PPP/SLIP) Interface

Физический адрес. . . . . . . . . : 00-53-45-00-00-00

Dhcp включен. . . . . . . . . . . : нет

IP-адрес . . . . . . . . . . . . : xx.xxx.xx.1

Маска подсети . . . . . . . . . . : 255.255.255.255

Основной шлюз . . . . . . . . . . : xxx.xxx.xx.1

DNS-серверы . . . . . . . . . . . : 10.10.10.1

10.10.10.1

ничем не отличается от данных получаемых от работающего сервера. ип адрес на ppp либо реальный, либо серый

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть сомнения по поводу правильности настроек IP. У вас точно выдача идет в диапазоне 192.168.0-10.хх?

 

10.10.10.1 - это и DNS и PPTP?

 

В выводе "Основной шлюз . . . . . . . . . . : xxx.xxx.xx.1 и IP-адрес . . . . . . . . . . . . : xx.xxx.xx.1" - это один и тот же IP?

Изменено пользователем replicant

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

10.10.10.x это адреса в локалке, а в ppp вот

 

Интернет - PPP адаптер:

 

DNS-суффикс этого подключения . . :

Описание . . . . . . . . . . . . : WAN (PPP/SLIP) Interface

Физический адрес. . . . . . . . . : 00-53-45-00-00-00

Dhcp включен. . . . . . . . . . . : нет

IP-адрес . . . . . . . . . . . . : xx.xxx.xx.1

Маска подсети . . . . . . . . . . : 255.255.255.255

Основной шлюз . . . . . . . . . . : xxx.xxx.xx.1

DNS-серверы . . . . . . . . . . . : 10.10.10.1

или тоже с серым

1 - PPP адаптер:

 

DNS-суффикс этого подключения . . :

Описание . . . . . . . . . . . . : WAN (PPP/SLIP) Interface

Физический адрес. . . . . . . . . : 00-53-45-00-00-00

Dhcp включен. . . . . . . . . . . : нет

IP-адрес . . . . . . . . . . . . : 192.168.1.7

Маска подсети . . . . . . . . . . : 255.255.255.255

Основной шлюз . . . . . . . . . . : 192.168.1.7

DNS-серверы . . . . . . . . . . . : 10.10.10.1

10.10.10.1

10.10.10.1 и днс и pptpd

Изменено пользователем Cramac

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В выводе "Основной шлюз . . . . . . . . . . : xxx.xxx.xx.1 и IP-адрес . . . . . . . . . . . . : xx.xxx.xx.1" - это один и тот же IP?

да, в любом варианте оба ип одинаковы

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Еще один вариант попробуйте, но для этого надо сесть с тестовым ПК или ноутом в подсеть с сервером 10.10.10.1 на адрес 10.10.10.х, чтобы сервер 10.10.10.1 был шлюзом у клиента.

 

Вручную добавить правило FORWARD в iptables и попробовать без vpn выйти в сеть. Отработает или нет сервер ситуацию с пробросом вручную клиента без pptp.

 

Если да, то копать дальше уже в сторону pptpd и около него.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

скорее всего проблема была в том что не на тот интерфейс ссылалось

правило было такого плана:

iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o eth0 -j SNAT --to-source 81.13.90.122

а сетевая с внешним у меня eth1

 

пока исправил но не проверял.

Изменено пользователем Cramac

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

скорее всего проблема была в том что не на тот интерфейс ссылалось

правило было такого плана:

iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o eth0 -j SNAT --to-source 81.13.90.122

а сетевая с внешним у меня eth1

 

пока исправил но не проверял.

А зачем вообще eth указывать, если у вас известно что -s 192.168.0.0/16 -d 0/0 ? В строке, которую я приводил для SNAT ранее никакого eth нет. Система сама определит направление согласно таблицам маршрутизации или пошлет по default gw пакет. Не улавливаю смысла в данном случае в указании -o eth

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.