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

Проблема с VPN-пользователями из 192.168.0.0/24 сетей

Сегодня поднял VPN (L2TP+IPSec) на 951G-2HnD, все завелось и запустилось, удаленщики подключаются, доступ к требуемым внутренним ресурсам имеют.

Изначально, внутренняя адресация в компании использована 192.168.0.0/24, требуемый внутренний узел с RDP-сервером имеет злополучный адрес 192.168.0.1

 

Обнаружилась проблема с теми удаленными пользователями, которые подключаются из аналогичных сетей 192.168.0.0/24, где адресом основного шлюза прописан 192.168.0.1

Достучаться от таких после установки VPN-соединения до указанного внутреннего сервера с 192.168.0.1 уже не удается, запросы не уходят в канал, а адресуются на 0.1 той же сети, откуда происходит подключение удаленщика. При этом остальной трафик идет именно в поднимаемый канал, интернет уже начинает работать через уделенное подключение.

Причем пользователи с Win7 могут получить доступ к другим адресам удаленной подсети 192.168.0.0/24 за исключением 0.1-го адреса, пользователи же WinXP вообще не имеют доступа ни к одному адресу в удаленной 192.168.0.0/24.

 

C этим что-то можно поделать или без отказа от 192.168.0.0/24 и перехода на другую адресацию на фирме с перенастройкой всего оборудования ничего не сделать?

 

Вывод route print на WinXP

C:\Documents and Settings\Пользователь>route print
===========================================================================
Список интерфейсов
0x1 ........................... MS TCP Loopback interface
0x90002 ...00 23 54 48 7c b1 ...... Realtek RTL8168C(P)/8111C(P) PCI-E Gigabit E
thernet NIC - ¦шэшяюЁЄ яырэшЁют•шър яръхЄют
0xe0004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
         0.0.0.0          0.0.0.0      192.168.0.1   192.168.0.242       11
         0.0.0.0          0.0.0.0   192.168.89.252  192.168.89.252       1
  80.ХХХ.ХХХ.ХХХ  255.255.255.255      192.168.0.1   192.168.0.242       10
       127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
     169.254.0.0      255.255.0.0    192.168.0.242   192.168.0.242       20
     192.168.0.0    255.255.255.0    192.168.0.242   192.168.0.242       10
   192.168.0.242  255.255.255.255        127.0.0.1       127.0.0.1       10
   192.168.0.255  255.255.255.255    192.168.0.242   192.168.0.242       10
  192.168.89.252  255.255.255.255        127.0.0.1       127.0.0.1       50
  192.168.89.255  255.255.255.255   192.168.89.252  192.168.89.252       50
       224.0.0.0        240.0.0.0    192.168.0.242   192.168.0.242       10
       224.0.0.0        240.0.0.0   192.168.89.252  192.168.89.252       1
 255.255.255.255  255.255.255.255    192.168.0.242   192.168.0.242       1
 255.255.255.255  255.255.255.255   192.168.89.252  192.168.89.252       1
Основной шлюз:      192.168.89.252
===========================================================================
Постоянные маршруты:
 Отсутствует

 

Вывод route print на Win7

C:\Users\Александр>route print
===========================================================================
Список интерфейсов
27...........................
11...00 26 18 a7 5a cf ......Realtek PCIe GBE Family Controller
 1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP
13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
15...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP #2
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
         0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.243   4235
         0.0.0.0          0.0.0.0         On-link    192.168.89.252     11
  80.XXX.XXX.XXX  255.255.255.255      192.168.0.1    192.168.0.243   4236
       127.0.0.0        255.0.0.0         On-link         127.0.0.1   4531
       127.0.0.1  255.255.255.255         On-link         127.0.0.1   4531
 127.255.255.255  255.255.255.255         On-link         127.0.0.1   4531
     192.168.0.0    255.255.255.0         On-link     192.168.0.243   4491
   192.168.0.243  255.255.255.255         On-link     192.168.0.243   4491
   192.168.0.255  255.255.255.255         On-link     192.168.0.243   4491
  192.168.89.252  255.255.255.255         On-link    192.168.89.252    266
       224.0.0.0        240.0.0.0         On-link         127.0.0.1   4531
       224.0.0.0        240.0.0.0         On-link     192.168.0.243   4492
       224.0.0.0        240.0.0.0         On-link    192.168.89.252     11
 255.255.255.255  255.255.255.255         On-link         127.0.0.1   4531
 255.255.255.255  255.255.255.255         On-link     192.168.0.243   4491
 255.255.255.255  255.255.255.255         On-link    192.168.89.252    266
===========================================================================
Постоянные маршруты:
 Отсутствует

 

Может какие конфиги с Микротика показать?

Edited by mrrc

Share this post


Link to post
Share on other sites

Да, есть такая бяка в винде.

Я просто решил: во всех местах, где бываю - дом, брат, родители - поменял адресную сеть с 1.0/24 на 111.0/24. Так как в офисе 1.0

Либо пользюков с удаленки напрягать аналогично, либо алиасом вешать еще один адрес на твой РДП-сервер типа 192.168.11.1 и на подключение удаленщикам раздавать адреса из этой же сети.

 

в идеале, конечно, создать, не бриждованый, а маршрутизируемый туннель.

Чтобы обеспечить l2-Изоляцию. Только твой 951 может от этого сложиться по процессору при подключении человек так 10ти и интернете на 8-10 мегабитофф.

 

и в целях безопасности маршрутизировать ТОЛЬКО на указанный адрес. чтоб по удаленке по сети не лазили, например.

Share this post


Link to post
Share on other sites

Да, есть такая бяка в винде.

Я просто решил: во всех местах, где бываю - дом, брат, родители - поменял адресную сеть с 1.0/24 на 111.0/24. Так как в офисе 1.0

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

 

либо алиасом вешать еще один адрес на твой РДП-сервер типа 192.168.11.1 и на подключение удаленщикам раздавать адреса из этой же сети.

А это как вариант, т.е. вторым адресом повесить на RDP-сервер внутренней сети помимо 192.168.0.1 дополнительно 192.168.89.254, например?

Убрав его из пула выдаваемых микротиком адресов под vpn-пользователей. И "проблемным" удаленщикам давать этот 192.168.89.254 для rdp-подключений?

Share this post


Link to post
Share on other sites

для порядка проще всем удаленщикам. логи читать будет проще. и защита от НСД если чо - махом запилишь.

 

нет. стоп, у тебя как реализовано, еще раз:

микротик терминирует удаленное подключение, вешает маршрут и сквозь этот туннель ты запускаешь рдп? так?

Share this post


Link to post
Share on other sites

для порядка проще всем удаленщикам. логи читать будет проще. и защита от НСД если чо - махом запилишь.

Мысль я уловил, нужно будет попробовать, спасибо за идею!

 

нет. стоп, у тебя как реализовано, еще раз:

микротик терминирует удаленное подключение, вешает маршрут и сквозь этот туннель ты запускаешь рдп? так?

Да, подключение удаленщика, получение им адресации из 192.168.89.2-254 и по созданному тоннелю уже rdp на 192.168.0.1

Edited by mrrc

Share this post


Link to post
Share on other sites

UPD: перечитал, вроде правильно все понял. Ну да, самое простое - второй адрес. А на будущее совет - не используй нигде ничего стандартного. Вот типичный пример. ))

 

не вопрос) обращайся))

Share this post


Link to post
Share on other sites

UPD: перечитал, вроде правильно все понял. Ну да, самое простое - второй адрес. А на будущее совет - не используй нигде ничего стандартного. Вот типичный пример. ))

Это уже давно наука, но от прежних своих или чужих ошибок не застраховаться.

Кстати, на Микротике еще пришлось прописать route до адреса 192.168.89.254 на ether2 (интерфейс, к которому подключена локалка в офисе), иначе для удаленщика 254-й был недоступен.

Edited by mrrc

Share this post


Link to post
Share on other sites

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

 

Поставить вторым адресом на 1С\RDP сервере во внутренней (.0/24) локальной сети IP 192.168.89.254, в настройках подключения у удаленщиков снимать галку в настройках TCP/IP использование основного шлюза в удаленной сети, чтобы не прогонять интернет через vpn у подключающихся пользователей, дав возможность работать только с удаленным адресом 192.168.89.254 DRP-сервера независимо от одновременного решения других задач в Интернет.

 

Натим сеть 192.168.89.0/24 на интерфейс ether2, к которому подключена внутренняя локальная сеть 192.168.0.0/24, в которой находится IP 192.168.89.254.

/ip firewall nat add action=masquerade chain=srcnat out-interface=ether2 src-address=192.168.89.0/24

Ставим route до указанного адреса на ether2

/ip route add distance=1 dst-address=192.168.89.254/32 gateway=ether2

Share this post


Link to post
Share on other sites

Вам просто нужно включить Proxy ARP на интерфейсе локальной сети где находится 192.168.0.1/24, а в настройках DHCP сервера убрать часть диапазона на раздачу, например оставить только 192.168.0.100-200, тогда абонентам по VPN можете раздавать адреса 192.168.0.201-254 и все будет работать без разных лишних манипуляций.

Share this post


Link to post
Share on other sites

Во внутренней сети 192.168.0.0/24 адресация статическая на десять компов, DHCP не используется туда, но смысл понятен.

Только встает вопрос, если удаленщикам под vpn-соединения будут выдаваться адреса из 0-вой подсети, при этом они сами будут уже находиться в таковой на своих удаленных рабочих местах, не возникнет ли конфликтов с существующей адресацией у них в этом случае. Т.е. предположим у удаленщика уже присвоен адрес в сети 0.250, а тут еще этот же адрес назначается по поднятому vpn-соединению.

Все же вариант, предложенный diter2001, мне видится более рабочим и удобным в данном случае.

Share this post


Link to post
Share on other sites

Натим сеть 192.168.89.0/24 на интерфейс ether2, к которому подключена внутренняя локальная сеть 192.168.0.0/24, в которой находится IP 192.168.89.254.

 

/ip firewall nat add action=masquerade chain=srcnat out-interface=ether2 src-address=192.168.89.0/24

 

С выделенного начнутся глюки. Догадаетесь, почему?

Edited by nkusnetsov

Share this post


Link to post
Share on other sites

Проще и удобнее сделать следующее:

1) Удаленщикам назначать адреса например, из диапазона 192.168.89.10-200 (ну или сколько их вам надо). У них должна быть убрана галка "use default gateway..."

2) В свойствах pptp/l2tp сервера указать локальный адрес 192.168.89.1

3) Удаленщикам в качестве адреса RDP-сервера указывать 192.168.89.1, а фаерволом делать dst-nat на настоящий адрес RDP-сервера

 
/ip firewall nat add action=dst-nat chain=dstnat dst-address=192.168.89.1 dst-port=3389 protocol=tcp to-addresses=192.168.0.xxx

Плюсы:

1) Почти всё делается на микротике

2) Не надо корячить IP на сервере

Edited by nkusnetsov

Share this post


Link to post
Share on other sites

Ну что ж, спасибо, такой вариант работает, плюсы принимаются.

Только хотелось бы пояснения по:

 

1) Удаленщикам назначать адреса например, из диапазона 192.168.89.10-200 (ну или сколько их вам надо). У них должна быть убрана галка "use default gateway..."

Почему не 192.168.89.2-254?

 

С выделенного начнутся глюки. Догадаетесь, почему?

Все же в чем тут предполагалась проблема? Нужен src-address с иной маской подсети из-за отсутствия в подсети одного из IP?

Share this post


Link to post
Share on other sites

Ну что ж, спасибо, такой вариант работает, плюсы принимаются.

Только хотелось бы пояснения по:

 

1) Удаленщикам назначать адреса например, из диапазона 192.168.89.10-200 (ну или сколько их вам надо). У них должна быть убрана галка "use default gateway..."

Почему не 192.168.89.2-254?

 

С выделенного начнутся глюки. Догадаетесь, почему?

Все же в чем тут предполагалась проблема? Нужен src-address с иной маской подсети из-за отсутствия в подсети одного из IP?

Можно удаленщикам и 192.168.89.2-254. Тут не принципиально. Просто для примера диапазон. Главное чтоб в подсеть /24 входил.

 

/ip firewall nat add action=masquerade chain=srcnat out-interface=ether2 src-address=192.168.89.0/24

Глюки будут потому, что в правиле прописано действие src-nat на src-address 192.168.89.0/24 а про дополнительный адрес на интерфейсе ether2 не упоминается. Хотя возможно в том примере я что-то недопонял или вы что-то недописали.

UPD: перечитал на пост выше, увидел про адрес на ether2. Ага. Тогда не должно глюкать. Но лишние route и masquerade всегда лучше избегать.

Edited by nkusnetsov

Share this post


Link to post
Share on other sites

UPD: перечитал на пост выше, увидел про адрес на ether2. Ага. Тогда не должно глюкать. Но лишние route и masquerade всегда лучше избегать.

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

Но предложенными вами вариант изящней, конечно.

Share this post


Link to post
Share on other sites

Во внутренней сети 192.168.0.0/24 адресация статическая на десять компов, DHCP не используется туда, но смысл понятен.

Только встает вопрос, если удаленщикам под vpn-соединения будут выдаваться адреса из 0-вой подсети, при этом они сами будут уже находиться в таковой на своих удаленных рабочих местах, не возникнет ли конфликтов с существующей адресацией у них в этом случае. Т.е. предположим у удаленщика уже присвоен адрес в сети 0.250, а тут еще этот же адрес назначается по поднятому vpn-соединению.

Все же вариант, предложенный diter2001, мне видится более рабочим и удобным в данном случае.

 

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

Share this post


Link to post
Share on other sites

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

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

В предлагаемом вами варианте реализации применительно к моему вопросу, как я понимаю, достаточно настроенного на шлюз=микротик самого DRP-сервера с 192.168.0.1, а не всей остальной внутренней сети 0/24 (тут зависит от поставленных задач, конечно).

Общий смысл сказанного вами я понял, проверять на практике уже не стал, меня только смущает уже озвученный мною выше момент с возможным пересечением адресного пространства 192.168.0.0/24, выделяемого под пул vpn-пользователей, с уже имеющейся такой же подсетью у самих удаленных подключающихся пользователей. Например, у кого-то на удаленном компе стоит 192.168.0.254 и после инициализации им vpn-соединения, ему прилетает тот же 0.254, скажем.

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

Надеюсь, изложил понятно и вас понял тоже верно.

Share this post


Link to post
Share on other sites

Если в сети есть DHCP сервер то у него есть пул, и этот пул можно дополнительно использовать и для подключения по VPN, тогда конфликтов адресов не будет. Конечно, если руками их не ставят.

Share this post


Link to post
Share on other sites

Если в сети есть DHCP сервер то у него есть пул, и этот пул можно дополнительно использовать и для подключения по VPN, тогда конфликтов адресов не будет. Конечно, если руками их не ставят.

Мы с вами о разных вещах говорим, вы мне про раздачу и назначение внутри своей локальной сети и для vpn-пользователей, а я про адресацию у удаленщиков\мобильщиков и т.д.

Я организую у себя vpn-сервер, даю вам учетку для подключения и необходимые инструкции для работы, откуда вы ко мне будете подключаться и какие у вас при этом будут местные подсети - мне не известно, не исключаю, что может быть и из такого же диапазона 192.168.0.0/24

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.