LINUX.ORG.RU
решено ФорумAdmin

Маршрутизация подсетей разных классов через разные шлюзы на удаленные клиенты

 , , , ,


0

2

Добрый день, форумчане. у меня возникла проблема которую уже неделю не могу решить и даже могущественный дядя гугл не помогает. Есть основной офис.в нем такая структура: 1. DC - контроллер домена + dhcp 192.168.10.2/16 2. proxy-server и он же почтовый на линуксе centos 6. два интерфеса. один в нет по statick ip, а другой в локалку. 3. VPN сервер (сеntos 6) подключений от удаленных филиалов. к нему подключаются RODC (контроллеры домена только для чтения). клиенты удаленных филиалов видят ресурсы основного офиса. имеет одну сетевую карту с ip в офис 192.168.10.17. по dhcp выдает удаленным клиентам statick ip. теперь самое печальное: сеть офиса имеет адрес 192.168.10.0/16 на филиалы 192.168.30.0/24 и другой филиал 192.168.20.0/24 филиалы подключены через VPN к серверу. маршуры в филиале прописаны такие net 192.168.10.0/16 через VPN. тогда инет в филиалах ходит через свой канал и есть доступ к ресурсам. у клиентов прописан в филиалах шлюз на местный RODC с маршрутизацией Проблема в следующем: у офиса нет доступа к филиальным клиентам. только к RODC. напрямую не пробрасывается трафик до компа. с филиального компа до офисного есть доступ. пробема похоже в том, что у офиса дефолтный шлюз прописан местный прокси, а не VPN сервер. Вопрос в том КАК в iptables указать, что при запросе ip адреса относящегося к подсети 192.168.20.0 передать его на другой шлюз, где трафик будет проброшен в соответствующий филиал. вторая проблема в том, что бы пробросит этот трафик на сервере RODC (win2008 r2 st) средстами маршрутизации до клиентского пк. пока только связь односторонняя получается. и под конец. стоит в офисе и филиалах специализированное ПО. менять подсети и нумерацию сетей не возможно. есть какие идеи?

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

pianolender ★★★ ()

есть какие идеи?

Во первых уясни, наконец, адресацию. В классовой маска не нужна. Классовая адресация уже 100 лет в обед не используется. Во-вторых у тебя перекрытие сетей. Для разруливания используется маска. В третьих - написанное воспринимается трудно. Рисуй схему сети, где укажи все устройства и их айпишники (обязательно с маской или префиксом).

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

[IMG]http://s57.radikal.ru/i157/1311/31/e40e34b14091t.jpg[/IMG] схема очень упращеная. у прокси две сетевухи. у vpn сервера одна. подсети обведены красным. доступ к удаленных клиентов есть в сеть в том числе и к другим серверам: KMS, системам мониторинга и т.д. а у офисных нету к клиентам филиала. максимум к серdерам RODC

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

Именно через маску и сделан о.

Заголовок почитай.

Проблема в следующем: у офиса нет доступа к филиальным клиентам.

И не будет. У тебя сетки перекрываются, а за пределы непосредственно подключенной сети ты не выскочишь без маршуртов с другой административной дистанцией (и/или) метрикой. У тебя в сетку 192.168.10.0/16 входят 192.168.20.0/24 и 192.168.30.0/24. Не в обиду сказано, но эта убогая схема без интерфейсов с адресами бесполезна. Лень рисовать - это твои вопросы.

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

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

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

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

что пришедшие пакеты нужно не у себя оставлять а отправлять дальше по сети

Вы вообще не в курсе, что такое маршрутизация. Если нет маршрута на конкретную сетку, то пойдет по default gateway. Если маршрута на адрес вообще нет, то будет дроп. Как смотреть таблицу маршрутизации думаю найдете (в linux, например, route -n). iptables - это не к вопросу маршрутизации. Посмотреть iptables ( iptables -L; iptables -t nat -L)

сетка не маленькая, а там маршрутизация серьезная

куда уж серьезней. я плакалъ

andrew667 ★★★★★ ()
Ответ на: комментарий от andrew667
192.168.20.0    192.168.20.200  255.255.255.0   UG    0      0        0 eth0

маршрут есть. с подсети 192.168.20.0/24 отпрвляет на RODC который доступен и на котором маршрутизация. и это не работает. на RODC нужно прописывать дополнительно маршруты? если да то какие?

mustwin ()

Перекрывающиеся сети зло. Делать такую конструкцию нужно только в оооочень крайнем случае ( и для этого прочитать про proxyarp ).

Сеть офиса не может быть 192.168.10.0/16! Либо 192.168.0.0/16 либо 192.168.10.0/24, либо 192.168.8.0/21

проще сеть 192.168.0.0/16 переделать в 192.168.10.0/24 или 192.168.10.0/23 и не трогать филиалы.

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

поправка. из офисной сети отправляет на 192.168.20.200 при запросе адресов с той подсети. и все равно нет доступа к клиентам.

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

переделать нельзя. приходиться работать с тем, что есть. сеть офиса 192.168.0.0 но идет большое адресное пространство для других клиентов. а клиенты кто должен иметь доступ имеют ip 192.168.10.хх. настроено через резервирование и заблокирована раздача ip в диапозоне 192.168.10.0-192.168.30.254

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

Я бы мог объяснить тебе почему у тебя доступен DC, но ты должен прийти к этому сам глядя в свою схему. Изучай как устанавливается соединение и что такое proxy arp.

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

Перекрывающиеся сети зло. Делать такую конструкцию нужно только в оооочень крайнем случае

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

proxyarp

Тут люди с адресацией разобраться не могут, а ты им еще один непосильный костыль советуешь.

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

маршрут есть.

где есть? в астрале? я не ясновидящий. В общем разбирайся сам. Внятно даже структуры сети не знаешь и таблицы маршрутизации всех узлов.

andrew667 ★★★★★ ()

Ну раз ничего менять нельзя, а ты ССЗБ то пропиши на всех машинах в офисе маршруты в сети филиалов через VPN-сервер и успакойся.

hoggor ()

> 192.168.10.2/16

Сам виноват. Кроме того -

> dhcp

> переделать нельзя

- не верю.

berrywizard ★★★★★ ()

менять подсети и нумерацию сетей не возможно

боюсь спросить за вашу должность?

vxzvxz ★★★ ()

проблема решилась. Нужно было на проксе офиса прописать маршруты в соответствующие подсети и настроить проброс в iptables. в филиалах настроить проброс подсети офиса на интерфейс сервера RODC. А что бы не было наложений сетей использовал промежуточную маршрутизацию на сервере VPN. И никаких маршрутов клиентам писать не надо. клиентов ведь больше 3х тысяч.

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

Мне даже интересно стало каким боком это у вас заработало без добавления маршрутов в сети 20.0/24 и 30.0/24?

Вот PC1 в подсети 0.0/16 хочет обратится к PC2 в подсети 20.0/24, он видит (судя по своей маске сети), что PC2 в его широковещательном домене. Делает ARP-запрос «дайте MAC хоста 192.168.20.xxx!» и естественно не получает ответа (без proxy arp). Каким образом пакет у вас вообще доходит до def gw?

anonymous ()

Прошу очень внимательно читать мои посты. Я не говорил, что у меня не настроин прокси арп. задал конкретный вопрос, на который так и не получил ответ, а кучу высказываний и ни одного по делу. Прокси арп настроен и работает должным образом. а спрашивал я про МАРШРУТЫ. Просто переработал и зациклился не на том. сам вспонил и сделал. тема закрыта

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