Jump to content
Калькуляторы

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

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

--------

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

 

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

Edited by replicant

Share this post


Link to post
Share on other sites

 

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

адреса типо

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

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

Share this post


Link to post
Share on other sites

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

 

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 включено (хотя, если реальники работают, то должно быть включено)?

Edited by replicant

Share this post


Link to post
Share on other sites

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

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

 

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

Edited by Cramac

Share this post


Link to post
Share on other sites

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

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

Edited by replicant

Share this post


Link to post
Share on other sites
>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 либо реальный, либо серый

Share this post


Link to post
Share on other sites

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

 

10.10.10.1 - это и DNS и PPTP?

 

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

Edited by replicant

Share this post


Link to post
Share on other sites

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

Edited by Cramac

Share this post


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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

Edited by Cramac

Share this post


Link to post
Share on other sites
скорее всего проблема была в том что не на тот интерфейс ссылалось

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this