Цель
Необходимо организовать VPN Tunnel между двумя устройствами, таких как Mikrotik и Juniper линейки SRX.
Что имеем
Из микротиков выбрали на сайте микротика вики, модель которая сможет поддерживать аппаратное шифрование IPSec, на наш взгляд она оказалась достаточно компактная и недорогая, а именно Mikrotik hEXS.
USB Modem был куплен в ближайшем сотовом операторе, модель была Huawei E3370. Никакие операции по отвязки от оператора мы не проводили. Все штатное и прошито самим оператором.
В ядре установлен центральный маршрутизатор Juniper SRX240H.
Что удалось
Удалось реализовать схему работы, которая позволяет через сотового оператора, не имея статического адреса, посредством модема создать IPsec соединение в который заворачивается GRE Tunnel.
Данная схема подключения используется и работает на USB модемах Билайн и Мегафон.
Конфигурация следующая:
В ядре установлен Juniper SRX240H
Local Address: 192.168.1.1/24
External Address: 1.1.1.1/30
GW: 1.1.1.2
Удаленная точка
Mikrotik hEX S
Local Address: 192.168.152.1/24
External Address: Dynamic
Небольшая диаграмма для понимания работы:
Конфигурация Juniper SRX240:
Версия ПО JUNOS Software Release [12.1X46-D82]
interfaces {
ge-0/0/0 {
description Internet-1;
unit 0 {
family inet {
address 1.1.1.1/30;
}
}
}
gr-0/0/0 {
unit 1 {
description GRE-Tunnel;
tunnel {
source 172.31.152.2;
destination 172.31.152.1;
}
family inet;
vlan {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
st0 {
unit 5 {
description "Area - 192.168.152.0/24";
family inet {
mtu 1400;
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 1.1.1.2;
route 192.168.152.0/24 next-hop gr-0/0/0.1;
route 172.31.152.0/30 next-hop st0.5;
}
router-id 192.168.1.1;
}
security {
ike {
traceoptions {
file vpn.log size 256k files 5;
flag all;
}
policy ike-gretunnel {
mode aggressive;
description area-192.168.152.0;
proposal-set standard;
pre-shared-key ascii-text "mysecret"; ## SECRET-DATA
}
gateway gw-gretunnel {
ike-policy ike-gretunnel;
dynamic inet 172.31.152.1;
external-interface ge-0/0/0.0;
version v2-only;
}
ipsec {
}
policy vpn-policy0 {
perfect-forward-secrecy {
keys group2;
}
proposal-set standard;
}
vpn vpn-gretunnel {
bind-interface st0.5;
df-bit copy;
vpn-monitor {
optimized;
source-interface st0.5;
destination-ip 172.31.152.1;
}
ike {
gateway gw-gretunnel;
no-anti-replay;
ipsec-policy vpn-policy0;
install-interval 10;
}
establish-tunnels immediately;
}
}
policies {
from-zone vpn to-zone vpn {
policy st-vpn-vpn {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
log {
session-init;
session-close;
}
count;
}
}
}
from-zone trust to-zone vpn {
policy st-trust-to-vpn {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
log {
session-init;
session-close;
}
count;
}
}
}
from-zone vpn to-zone trust {
policy st-vpn-to-trust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
log {
session-init;
session-close;
}
count;
}
}
}
zones {
security-zone trust {
vlan.0 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
security-zone vpn {
interfaces {
st0.5 {
host-inbound-traffic {
protocols {
ospf;
}
}
}
gr-0/0/0.1 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
security-zone untrust {
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
ping;
ssh;
ike;
}
}
}
}
}
vlans {
vlan-local {
vlan-id 5;
l3-interface vlan.1;
}Конфигурация Mikrotik hEX S:
Версия ПО RouterOS [6.44.3]
/ip address
add address=172.31.152.1/24 comment=GRE-Tunnel interface=gre-srx network=172.31.152.0
add address=192.168.152.1/24 comment=Local-Area interface=bridge network=192.168.152.0
/interface gre
add comment=GRE-Tunnel-SRX-HQ !keepalive local-address=172.31.152.1 name=gre-srx remote-address=172.31.152.2
/ip ipsec policy group
add name=srx-gre
/ip ipsec profile
add dh-group=modp1024 dpd-interval=10s name=profile1
/ip ipsec peer
add address=1.1.1.1/32 comment=GRE-SRX exchange-mode=aggressive local-address=172.31.152.1 name=peer2 profile=profile1
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-256-cbc,aes-128-cbc,3des
add enc-algorithms=aes-128-cbc,3des name=proposal1
/ip route
add distance=10 dst-address=192.168.0.0/16 gateway=gre-srx
/ip ipsec identity
add comment=IPSec-GRE my-id=address:172.31.152.1 peer=peer2 policy-template-group=srx-gre secret=mysecret
/ip ipsec policy
set 0 disabled=yes
add dst-address=0.0.0.0/0 proposal=proposal1 sa-dst-address=1.1.1.1 sa-src-address=172.31.152.1 src-address=172.31.152.0/30 tunnel=yes
/ip address
add address=172.31.152.1/24 comment=GRE-Tunnel interface=gre-srx network=172.31.152.0
add address=192.168.152.1/24 comment=Local-Area interface=bridge network=192.168.152.0
Результат:
Со стороны Juniper SRX
netscreen@srx240> ping 192.168.152.1
PING 192.168.152.1 (192.168.152.1): 56 data bytes
64 bytes from 192.168.152.1: icmp_seq=0 ttl=64 time=29.290 ms
64 bytes from 192.168.152.1: icmp_seq=1 ttl=64 time=28.126 ms
64 bytes from 192.168.152.1: icmp_seq=2 ttl=64 time=26.775 ms
64 bytes from 192.168.152.1: icmp_seq=3 ttl=64 time=25.401 ms
^C
--- 192.168.152.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 25.401/27.398/29.290/1.457 msСо стороны Mikrotik
net[admin@GW-LTE-] > ping 192.168.1.1
SEQ HOST SIZE TTL TIME STATUS
0 192.168.1.1 56 64 34ms
1 192.168.1.1 56 64 40ms
2 192.168.1.1 56 64 37ms
3 192.168.1.1 56 64 40ms
4 192.168.1.1 56 64 51ms
sent=5 received=5 packet-loss=0% min-rtt=34ms avg-rtt=40ms max-rtt=51ms Выводы
После проделанной работы му получили стабильный VPN Tunnel, из удаленной сети нам доступна все сеть которая находиться за juniper, и соответственно обратно.
Не рекомендую использовать в данной схеме IKE2, возникала ситуация что после перезагрузки того или иного устройства не поднимается IPSec.
Комментарии (23)
INSTE
09.06.2019 21:32Keenetic 4G дешевле в два раза, умеет все то же самое, при этом еще и IKEv2 работает стабильно.
AcidVenom
09.06.2019 23:16+1PCQ умеет? 2 и более провайдеров умеете? Скрипты умеет? Несколько подсетей умеет?
Это устройства разных классов, сравнивать их бессмысленно.INSTE
10.06.2019 10:31Много провайдеров — конечно. Скрипты — да. Несколько подсетей — пожалуйста.
AcidVenom
10.06.2019 10:42Внимание! При подключении к двум и более провайдерам, в интернет-центре серии Keenetic возможно использовать только резервирование подключений. Одновременно использовать подключение к нескольким интернет-провайдерам и балансировать их нагрузку невозможно.
Я, конечно, и дальше могу аргументировать, но это неравный бой.INSTE
10.06.2019 11:28Сначала определитесь с определением термина «балансировка», потом уже «вступайте в бой».
Выпускать конкретного клиента через конкретный WAN (любой) — это пара кликов в Web-интерфейсе. Есть экспериментальная опция для качающих торренты, которая включает ECMP-роутинг и позволяет грузить все каналы на полную, но она ломает работу с некоторыми ресурсами и не рекомендуется для обычных пользователей.
Ну и документация могла немного устареть.
INSTE
10.06.2019 11:35Это устройства разных классов, сравнивать их бессмысленно.
Да, разных, никто не спорит. Но все, что сделал автор (тут вроде обсуждение статьи идет, а не потенциальных ТТХ), можно было сделать на устройстве в 2 раза дешевле и с большим выхлопом.AcidVenom
10.06.2019 11:48Так а чего в 2 раза-то? Можно и в 3 раза дешевле, можно и на коленке. Только это не приемлемо в производственной среде. Что-то я не замечал в Магните TP-Link'ов или Zyxel'ей.
Лично у вас сколько сетевых устройств легло в продакшене?
smilyfox
10.06.2019 18:56Я замечал. И то и другое. Только я не стал бы называть Магнит производственной средой. На действительном производстве господствуют различные вариации cisco, moxa и иже с ними.
Eagle_NN
10.06.2019 17:33По моему опыту Keenetic через несколько лет использования начинает глючить все сильнее… С микротиком такого не наблюдал.
Night_Snake
11.06.2019 23:00Да, кинетик последнее время стал уметь многое, что раньше мог только Микротик/ZyWall/DFL, т.е. устройства, изначально заточенные не под SOHO, а под вполне себе средний бизнес с филиальной сетью и т.д. А ешё на него можно поставить какой-нибудь *WRT и получить ещё больше возможностей (включая установку доп. пакетов).
Но при этом по функциональности микротик до сих пор сильно его опережает. Плюсом к этому, какой-нибудь hAP mini умеет ровно столько же (по функциям), сколько самый мощный CCR. И конфиг переносится элементарно, т.е. проблем с апгрейдом железки не возникает.
При всём уважении к кинетику, как говорится.
TimsTims
10.06.2019 08:35Usb модемы имели свойство глючить через 1-2 дня работы. И пока руками не ребутнешь — не заработает интернет. Причем обычная перезагрузка роутера не помогает, нужно обязательно обесточить модем.
AcidVenom
10.06.2019 10:53Они и сейчас имеют, потому что не рассчитаны на такие режимы работы. Для работы 24/7 есть другие устройства.
INSTE
10.06.2019 11:31Keeentic умеет делать power-cycle на несколько секунд на usb-порту модема, если он перестал работать. Этот штатный функционал есть уже много лет.
DaemonGloom
10.06.2019 11:47Да, то же умеет и Микротик из статьи. На сколько секунд выключать питание — задаётся параметров в команде (ну или в веб-интерфейсе).
Tufed
10.06.2019 12:51Сам недавно занимался подобной настройкой: Juniper с NetGate-ом подружил по IP-sec. Была в наличии сетка из Juniper-ов с VPN-ками дефлотно настроенными, и в неё добавили еще одну удаленную точку с NetGate в качестве шлюза. Я не сетевик ни разу, обычный админ самоучка. И для меня было малость трудновато перейти от стандартного Juniper-овского подхода по созданию VPN к общему с указанием ключей, приветствий, шифрований 1 и 2 фазы, количеством байт проверки и т.д… Кхм, я даже подумывал статью запилить на эту тему, но выглядеть она будет как у автора этой статьи, то есть очень коротко, но может быть полезной как справочный материал.
Night_Snake
11.06.2019 22:51Навскидку, у меня несколько вопросов:
1. зачем использовать aggressive вместо main?
2. df-bit copy — не самая удачная идея на туннельных интерфейсах. Во избежание дропов я бы всё-таки скидывал бит dont-fragment
3. Я так и не понял смысла натягивать gre поверх ipsec. Даже если принять во внимание, что микротик не умеет полноценный route-based ipsec, ваше объяснение выглядит немного непонятно.
Если за Juniper сидит вся оставшаяся /16, и трафик к ней нужно добавить в ipsec policy — то на микротике это довольно легко обходится грамотным составлением policy и роутингом (т.е. у вас ipsec encapsulation просто не возникнет: wiki.mikrotik.com/wiki/Manual:Packet_Flow)
4. Ещё есть вопросы, зачем использовать vlan.0 вместо routed-портов, зачем вы разрешаете ospf, если его не используете (или используете?) и почему у вас в конфиге Juniper режим v2-only, если IKEv2 вы использовать не рекомендуете. Но это уже придирки. Наверное :)
nomadmoon
ЯННП. На стороне Джуна у вас «белый» адрес 1.1.1.1, но при этом сорс и дестинейшен туннеля в 172.16.0.0/12… А на стороне микротика вообще белого адреса нет :\
DaemonGloom
Вы пропустили часть, в которой был поднят IPsec, внутри которого уже бегает gre. Тому вполне хватает одного белого адреса.
blind_oracle
Зачем тогда GRE? Если IPSEC в туннельном режиме уже есть и делает практически то же самое.
INSTE
Чтобы преподнести поддержку GRE как нечто крайне крутое и недостающее всем пользователям в мире наверное.
BigDrive Автор
IPsec на стороне Микротика шифрует весь трафик, соответственно либо надо сеть бить 192.168.0.0/17, либо если нужна вся доступная сеть 192.168.0.0/16, то Микротик будет не доступен из локальной сети, по этому шифруем трафик 172.31.xxx.xxx
BigDrive Автор
Вроде не пропустил, он есть.
BigDrive Автор
Белого адреса нет, через Cloud Микротика не работает. Поэтому только через серый.