Cramac Опубликовано 27 ноября, 2010 · Жалоба Всем привет. Собственно вопрос вот в чем, есть: сервер на нем все, биллинг, нат, пптпд делаю: делю на отдельно сервер с биллингом, отдельно нат с пптпд (аксель) сделал дубли правил с работающего сервера, правила ната, правила форвардинга. Клиент подключается, но интернета нет (пинги не ходят, ничего не работает, днс резолвится норм) при этом люди что имеют реальный ип, выходят в сеть нормально. Еще момент есть, судя по биллинг (УТМ) есть клиенты которые и с серыми ИП были в интернете (трафик капал на них) Что я делаю не так? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 27 ноября, 2010 (изменено) · Жалоба Первое что приходит в голову - это посмотреть iptables -nL и iptables -nL -t nat (запросто могли не включить поддержку NAT в ядре или не подгрузить модуль iptables). Второе - это посмотреть какие серые ip выдаются клиентам при подключении к серверу и правильно ли выдается ip (соотвественно ip-up, ip-down надо глядеть). Третье - сделать как минимум traceroute от клиента до сервера, до днс, до внешнего шлюза, до любого адреса в инете. Четвертое - самому прикинуться клиентом и посмотреть на ситуацию с точки зрения клиента, а не только по показаниям сервера. -------- Ждать, когда закапает трафик и ориентироваться только по этому - ошибка. Трафик вообще не показатель что все работает. Реальники работают очевидно потому что они не натятся, а форвардятся. Изменено 27 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 27 ноября, 2010 · Жалоба адреса выдаюся биллингом (к каждому абону свой ип привязан, статика) адреса типо 192.168.0-10.хх/32 пробовал форвардинг разрешать для всех, все равно # iptables -nLChain 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 natChain 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 пробовал быть клиентом, все заканчивается на сервере. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 27 ноября, 2010 (изменено) · Жалоба Попробуйте такое правило вместо того, что есть сейчас 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 включено (хотя, если реальники работают, то должно быть включено)? Изменено 27 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 27 ноября, 2010 (изменено) · Жалоба странно все это, потому как все эти правила скопировал с работающего сервера... может есть какие то различия (на рабочем стоит мандрива, а тут центос) 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 Изменено 27 ноября, 2010 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 27 ноября, 2010 (изменено) · Жалоба Внутренний IP сервера не попадает в диапазон адресов, который выдает биллинг клиентам pptp? Как выглядит при этом ipconfig /all на клиенте, когда тот подключен к серверу на примере windows клиента? Изменено 27 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 27 ноября, 2010 · Жалоба нет, у него из 10.10. диапозона Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 27 ноября, 2010 · Жалоба >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 либо реальный, либо серый Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 27 ноября, 2010 (изменено) · Жалоба Есть сомнения по поводу правильности настроек IP. У вас точно выдача идет в диапазоне 192.168.0-10.хх? 10.10.10.1 - это и DNS и PPTP? В выводе "Основной шлюз . . . . . . . . . . : xxx.xxx.xx.1 и IP-адрес . . . . . . . . . . . . : xx.xxx.xx.1" - это один и тот же IP? Изменено 27 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 27 ноября, 2010 (изменено) · Жалоба 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 Изменено 27 ноября, 2010 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 27 ноября, 2010 · Жалоба В выводе "Основной шлюз . . . . . . . . . . : xxx.xxx.xx.1 и IP-адрес . . . . . . . . . . . . : xx.xxx.xx.1" - это один и тот же IP? да, в любом варианте оба ип одинаковы Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 27 ноября, 2010 · Жалоба Еще один вариант попробуйте, но для этого надо сесть с тестовым ПК или ноутом в подсеть с сервером 10.10.10.1 на адрес 10.10.10.х, чтобы сервер 10.10.10.1 был шлюзом у клиента. Вручную добавить правило FORWARD в iptables и попробовать без vpn выйти в сеть. Отработает или нет сервер ситуацию с пробросом вручную клиента без pptp. Если да, то копать дальше уже в сторону pptpd и около него. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 27 ноября, 2010 · Жалоба спасибо, проверю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 28 ноября, 2010 · Жалоба попробовал, не заработало :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 1 декабря, 2010 (изменено) · Жалоба скорее всего проблема была в том что не на тот интерфейс ссылалось правило было такого плана: iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o eth0 -j SNAT --to-source 81.13.90.122 а сетевая с внешним у меня eth1 пока исправил но не проверял. Изменено 1 декабря, 2010 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 1 декабря, 2010 · Жалоба скорее всего проблема была в том что не на тот интерфейс ссылалосьправило было такого плана: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...