0
- 11.02.2015 - 15:40
|
Имеется терминальный сервер в датацентре, для доступа к нему организован VPN из офиса заказчика. Однако есть филиалы, которым также необходимо получать доступ к этому серверу. Светить его внешний IP нельзя. Как в таких случаях принято делать? Чтобы филиал подключался к внешнему IP-офиса, а его пробрасывало по внутреннему IP на сервер, который находится за VPN-ом? С обоих сторон Микротики, VPN поднят средствами IPSec на них. Или поднять в офисе PPTP-VPN-сервер, на который будут "дозваниваться" удаленные филиалы и уже оттуда чтобы маршрутизировались в датацентр? | |
1
- 11.02.2015 - 16:15
| во втором варианте накладных расходов будет больше, двойная инкапсуляция, а так все равно | |
2
- 11.02.2015 - 16:25
|
Я бы выбрал такой вариант: филиалы - сервер - [офис, терминальный сервер] т.е. сервер на "входе" в офисную сеть будет заниматься исключительно маршрутизацией, но при этом у него должен быть вырублены все средства удаленного управления (ручками из консоли). И сделана "замороженная система" (это когда физически вырубаются все средства редактирования и удаленного управления). | |
3
- 11.02.2015 - 16:26
| Тебе все равно нужно пакеты "разруливать" от филиалов и на ДЦ, поэтому пускать лишний трафик в локалку ИМХО неразумно. | |
4
- 11.02.2015 - 16:45
|
(3): А почему трафик в локалку то пойдет? Я на самом входном Микротике подниму PPTP-сервер и все. Роль этого Микротика - только VPN, так как основным интернет-шлюзом для локалки он не является | |
5
- 11.02.2015 - 16:51
|
l2tp для дозвона, а оттуда eoip внутрь серой сети вашего "палёного адинэса" я сто раз так делал :) | |
6
- 11.02.2015 - 16:56
| 0-Stepan Razin > а нельзя сразу филиалы на впн-датацентра завернуть? зачем эта петля с головным офисом? | |
7
- 11.02.2015 - 17:03
| это блть такая видимость защиты паленой бухии | |
8
- 12.02.2015 - 09:25
|
4-Stepan Razin > может немного не так выразился, но я имел ввиду именно это - разруливание пакетов до локалки. 6-40KHYTbIU > По условиям задачи. | |
9
- 12.02.2015 - 19:02
|
если сильно нужно будет, все равно же придут, и найдут куда форврд, и тд идея чисто маркетинговая, но кто же не хочет денег) | |
10
- 12.02.2015 - 19:20
| 0-Stepan Razin >микротик виртуальные туннели поддерживает? Если как на циске, то поднять ipsec vti с каждым филиалом и на том же роутере разруливать маршруты. | |
11
- 12.02.2015 - 19:34
| в микротках же openvpn есть, чего тут огород городить в чистом поле) | |
12
- 13.02.2015 - 17:00
|
ага, и ospf тоже ))) правда овпн порезан - без tls, udp и сжатия но зато tap-м можно оч легко сделать в LAN bridge ))) | |
13
- 13.02.2015 - 17:01
| насчет сжатия правда не уверен, просто выключал с обратной стороны | |
14
- 21.02.2015 - 19:57
|
Можно конечно извратиться и сделать так: Раз у тебя уже есть VPN от заказчика к датацентру. Ну так и сделай проброс для удаленных офисов через оборудование заказчика. *Важный момент, какой трафик и в каком объеме ходит, и достаточно ли емкости канала заказчика что бы через него прокачивать. | |
15
- 22.02.2015 - 18:39
|
(14): В этом и вопрос - простой порт-мапинг не будет с офисного IP в датацентр через VPN. Что-то надо мудрить, и собственно в этом и был главный вопрос. | |
16
- 22.02.2015 - 19:48
|
1.У заказчика в главном офисе есть VPN к датацентру, так? 2.У заказчика в главном офисе есть внешний IP, так? Если все это у него есть, тогда пробрасывай RDP порт с внешнего IP главного офиса на RDP сервер в датацентре. пример с PublicIP:40001 на DataCenterIP:3389 А из удаленного офиса подключаешься по RDP на PublicIP:40001 или я еще чего-то не понимаю? | |
17
- 22.02.2015 - 19:50
| "В этом и вопрос - простой порт-мапинг не будет с офисного IP в датацентр через VPN." - Почему? | |
18
- 22.02.2015 - 20:35
|
кстати да, Почему? потому что ip RDP сервера == public ip датацентра? учитывая стаж автора на форуме, смею заметить, что постановка вопроса весьма корявая) | |
19
- 22.02.2015 - 20:40
| если rdp-сервер имеет внутренний, частный ip, то банальный проброс вполне нативно будет маршрутизироваться в VPN. | |
20
- 22.02.2015 - 20:43
| 19-gloomymen > +1 | |
21
- 22.02.2015 - 20:48
|
да даже неважнокакой, сачтный или публичный, маршрут же на него есть, если клиенты из офиса на него ходят, вот на него и делать проброс другое дело, если raw-rdp от филиалов считается некошерным, тогда да, нужен входящий туннель | |
22
- 23.02.2015 - 05:32
| можно и так и так, но как-то странно с чистым рдп раз то свои же филиалы, полезнее сразу по-моему делать тунели L3 и разруливать маршруты + на центральном фаерволить уже внутрянку кому куда можно ну и канал надо чтоб в центре не узкий был. IPSec на тиках даже не пробовал, а вот с ovpn(tun он же у тика "mode ip") + ospf вполне себе работает, если заморочиться можно подобие cisco dmvpn устроить. | |
23
- 08.01.2017 - 00:33
|
В общем, если кому интересно - в Микротике это решается одной (!) командой: /ip firewall nat add chain=dstnat action=netmap to-addresses=2.2.2.2 to-ports=3389 protocol=tcp in-interface=WAN dst-port=3389 log=yes log-prefix="" comment="PortMap-to-Another-Network" | |
24
- 09.01.2017 - 12:41
| ну обычный проброс порта | |
25
- 09.01.2017 - 13:58
| Обычный проброс порта - это dst-nat. А это netmap, по другому ещё называется "1:1 NAT" | |
| Интернет-форум Краснодарского края и Краснодара |