LINUX.ORG.RU
ФорумAdmin

Вопрос по шлюзу

 ,


0

1

Ребята, помогите разобраться. Имеется CentOS 6.5, на котором крутится Asterisk. После недолгих раздумий было принято решение (не мной) использовать этот же сервер, как интернет-шлюз и DHCP-сервер. И если с DHCP проблем не возникло, то со шлюзом что-то не задалось.

Подключение к провайдеру производится через pptp Имеются 2 учетки для подключения: На одной 30Мбит/сек и «белый» IP, на второй - 100Мбит/сек и «серый» IP. На учетку с «белым» IP настроен роутер, которому присвоен ip 192.168.1.250

Далее сервер. Имеются 3 интерфейса: 1) eth0 - он смотрит в локальную сеть провайдера и через него работает SIP. 2) eth3 - он смотрит опять же в сторону провайдера и на нем поднимается PPTP-соединение от провайдера для выхода в интернет 3) eth4 - смотрит во внутреннюю локальную сеть, где находятся все ПК офиса и роутер. Так же уже поднят ppp0 до провайдера, который удачно работает.

net.ipv4.ip_forward = 1

Проблема заключается в том, что этот самый сервер пихает весь трафик через eth4 и шлет все это через роутер с 30Мбит и «белым» IP, то есть eth4 --> eth4. Как заставить его пускать весь трафик через поднятое ppp0-соединение (eth4 --> eth3/ppp0)

:INPUT ACCEPT [2400:455212]
:FORWARD ACCEPT [193507:126985463]
:OUTPUT ACCEPT [1292:386259]
COMMIT
# Completed on Thu Aug 6 14:19:54 2015
# Generatea by ptables-save v1.4.7 on Thu Aug 6 14:19:54 2015 *filter
:INPUT ACCEPT [2400:455212]
:FORWARD ACCEPT [193507:126985463]
:OUTPUT ACCEPT [1292:386259]
COMMIT
# Completed on Thu Aug 6 14:19:54 2015
# Generated by iptables-save v1.4.7 on Thu Aug 6 14:19:54 2015 *nat
:PREROUTING ACCEPT [5:803]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o eth+ -j MASQUERADE
-A POSTROUTING -o ppp+ -j MASQUERADE
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT

mo1seev ()
Ответ на: комментарий от generator

10.0.0.5 dev ppp0 proto kernel scope link src 172.17.222.106
172.16.4.38 via 10.3.11.1 dev eth0 src 10.3.11.2
172.16.3.14 via 10.6.117.1 dev eth3 proto static
10.3.11.0/26 dev eth0 proto kernel scope link src 10.3.11.2
172.16.5.0/24 via 10.6.117.1 dev eth3 proto static
10.6.117.0/24 dev eth3 proto kernel scope link src
10.6.117.65
172.16.2.0/24 via 10.3.11.1 dev eth0
172.16.2.0/24 via 10.6.117.1 dev eth3 proto static
192.168.1.0/24 dev eth4 proto kernel scope link src
192.168.1.248 172.16.0.0/16 via 10.3.11.1 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth4 scope link metric 1003
169.254.0.0/16 dev eth3 scope link metric 1004
10.0.0.0/8 via 10.3.11.1 dev eth0
10.0.0.0/8 via 10.6.117.1 dev eth3 proto static

mo1seev ()
Ответ на: комментарий от generator

Какой именно маршрут должен быть по-дефолту?
Знаю, что задаю глупые вопросы, но все же.

mo1seev ()
Ответ на: комментарий от generator

Видимо, не до конца выделил ip ro
default via 192.168.1.250 dev eth4
Я так понимаю, что мне необходимо указать
default via 192.168.1.248 dev ppp0

mo1seev ()
Ответ на: комментарий от mo1seev

Дефолт должен быть через ppp0, правильно. Хотя, наверно вручную его лучше не менять. Надо почитать документацию к vpn клиенту, у него в конфиге должно быть что-то типа «defaultroute». Тогда про подключениии, он сам добавит маршрут.

generator ★★★ ()
Ответ на: комментарий от mo1seev

Не надо присваивать. Попробуй тогда вручную маршрут прописать.

generator ★★★ ()

После недолгих раздумий было принято решение использовать этот же сервер

боль

Подключение к провайдеру производится через pptp

еще больше боли.

вопрос - нахрена ты все маскуешь а не только внешку?

и да, нету default

upcFrost ★★★★★ ()
Ответ на: комментарий от upcFrost

В общем, проблему я решил, но как водится, образовалась куча новых. Так уж выходит, что у провайдера стоит целый пул шлюзов, насколько я выяснил, шлюзов аж целых 20: с 10.0.0.1 до 10.0.0.20. Каждый раз, когда поднимается PPTP - адрес шлюза выпадает разный. Как решить проблему с default gateway?

mo1seev ()
Ответ на: комментарий от mo1seev

а провайдер его вообще никак не передает? pptp у провайдеров обычно все-таки динамический в плане адреса (или псевдодинамический с точки зрения провайдера если есть привязка, клиенту все одно), для динамики шлюз должен передаваться в каком-то виде

Вообще в случае полной задницы, пресса начальством и пролета по срокам (если это какой проект висит) можно прописать 20 маршрутов статикой с разным preference, удачный маршрут все равно кэшируется. Но лучше разобраться.

upcFrost ★★★★★ ()
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от upcFrost

Везде указано «defaultroute». Да и адрес vpn-шлюза у меня указан не через ip, а через доменное имя «vpn.mannet.ru» Плюс ко всему, после поднятия подключения, сервак стал гулять по «серому ip». А как самого его вернуть на «белый», то есть на шлюз 192.168.1.250?

mo1seev ()
Ответ на: комментарий от mo1seev

inbound NAT, просто пробрось нужные тебе внешние порты шлюза на сервак (для астера - регистрация и транки если порты разные, может еще потребоваться nat trav, rtp обычно работает без форварда, но в случае косяка можешь вырубить directmedia/reinvite и пробросить порты на него тоже). Либо если тебе нужно чтоб на него что вообще все - поставь его как DMZ.

про шлюз через доменное имя - странно что глючит. У тебя его нигде не кэширует? Если ты получаешь dns от прова, то он автоматом должен разрешать нужное имя так или иначе

upcFrost ★★★★★ ()
Последнее исправление: upcFrost (всего исправлений: 2)
Ответ на: комментарий от mo1seev

ок... а если просто прицепить ноут к шнурку внешки, вычистить таблицу маршрутов и включить vpn со свежим конфигом (с нуля) - он получит гейт?

upcFrost ★★★★★ ()
Ответ на: комментарий от mo1seev

ок. Есть ли что-нибудь в логах? Можешь скинуть конфиг для pptp? Еще проверь как разрешается доменное имя шлюза после нескольких реконнектов. Также советую сделать голую LiveUSB с тем, что у тебя на сервере - в целях теста, чтоб была чистая установка. А лучше две-три, одну голую, одну обновить до сервера, одну обновлять до предела каждый раз

upcFrost ★★★★★ ()
Ответ на: комментарий от upcFrost

Содержание options.pptp:

lock

noauth

refuse-pap
refuse-eap
refuse-chap
refuse-mschap

nobsdcomp
nodeflate

mo1seev ()
Ответ на: комментарий от mo1seev

ну вообще не вижу особых проблем (можт туплю). И он вообще не создает default route? Ну, точнее - он создает хоть какой-нибудь маршрут при подключении если тоннель руками опустить и поднять?

upcFrost ★★★★★ ()
Ответ на: комментарий от upcFrost

Он вообще его не создает. Вот список при поднятом pptp:

172.16.3.14 via 10.6.117.1 dev eth3 proto static
172.16.4.41 via 10.3.11.1 dev eth0 src 10.3.11.2
10.0.0.8 dev ppp0 proto kernel scope link src 172.17.222.106
10.3.11.0/26 dev eth0 proto kernel scope link src 10.3.11.2
172.16.5.0/24 via 10.6.117.1 dev eth3 proto static
10.6.117.0/24 dev eth3 proto kernel scope link src 10.6.117.65
172.16.2.0/24 via 10.3.11.1 dev eth0
172.16.2.0/24 via 10.6.117.1 dev eth3 proto static
192.168.1.0/24 dev eth4 proto kernel scope link src 192.168.1.248
172.16.0.0/16 via 10.3.11.1 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth4 scope link metric 1003
169.254.0.0/16 dev eth3 scope link metric 1004
10.0.0.0/8 via 10.3.11.1 dev eth0
10.0.0.0/8 via 10.6.117.1 dev eth3 proto static
default via 192.168.1.250 dev eth4

mo1seev ()
Ответ на: комментарий от mo1seev

Попробуй запустить дебаг и проверить выхлоп в консоль. Об этом есть кусок в вики арча. Другие куски вики кстати тоже можно посмотреть

https://wiki.archlinux.org/index.php/PPTP_VPN_client_setup_with_pptpclient

дистроспецифика будет, но в целом почти всегда один в один

upcFrost ★★★★★ ()
Ответ на: комментарий от upcFrost

С пулом шлюзов я разобрался. Необходимо просто после поднятия ppp0 добавлять общий маршрут:
route add default dev ppp0
Но теперь возник другой вопрос. Как заставить сам сервак ходить по старому маршруту 192.168.1.250 (туда, где белый IP)? Я так понимаю, надо научить фаервол делить трафик и отправлять сервак через 192.168.1.250, а все остальное через ppp0?

mo1seev ()
Ответ на: комментарий от mo1seev

а, я думал оно не пашет даже после добавления маршрута. Ок, хорошо.

По поводу разделения трафика - PBR

http://superuser.com/questions/376667/how-to-route-only-specific-subnet-sourc...

Не уверен будут ли проблемы из-за того что сервер и сам ко всему является шлюзом, но думаю таблицу накидать можно будет.

upcFrost ★★★★★ ()
Ответ на: комментарий от mo1seev

Policy-Based routing. По сути то, что я скинул. Стандартная модель маршрутизации опирается на dest ip. PBR позволяет расширить это дополнительными критериями типа кто, по какому протоколу и т.д. Критерии сводятся в таблицы-политики (policy table). Кстати, эта штука может хорошо грузить проц если очень много правил и подключений

типичный пример использования - как раз твой случай, когда несколько гейтов и их обычной политикой разделить сложно

upcFrost ★★★★★ ()
Последнее исправление: upcFrost (всего исправлений: 2)
Ответ на: комментарий от upcFrost

Снова взываю о помощи. Создал таблицу и заставил весь трафик гулять через нужный мне ppp0, прописав всего лишь:
route add defaul ppp0

Далее создал таблицу T1 для шлюза:
default via 192.168.1.250 dev eth4

И сделал доступным сервер через несколько аплинков:
ip route add default via 192.168.1.250 table T1
ip rule add from 192.168.1.248 table T1

И все вроде бы заработало, но сам сервер так и гуляет через ppp0 с «серым» ip. Как заставить его лично ходить через шлюз 192.168.1.250 с нужным мне «белым» ip? Долго курил мануалы по маркировке трафика и т.д., но ничего дельного мне не удалось.

mo1seev ()
Ответ на: комментарий от mo1seev

возможно тогда надо пойти «от противного» - прописать дефолт как надо серверу и pbr как надо всем остальным. но предварительно выпиши в файл маршруты чтоб быстро восстановить в случае жопы.

кстати, в будущем советую хотя бы логически (контейнеры с квотами) разделить телефонию, dhcp и шлюз, это взрывоопасная комбинация. шлюз в контейнере не фонтан, а вот астер - вполне живет

upcFrost ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.