Juniper SRX в качестве VPN-сервера
... Допустим, хочется попадать на какие-то домашние сервисы наподобие видеокамер. Через "голый интернет" открывать это всё не очень хочется, а китайским облакам вы не доверяете. Значит нужен VPN-сервер. Понятно что технически его можно сделать из чего угодно, я вот решил склепать из Juniper SRX 300.
Вот здесь я уже делал один подход к снаряду. Но тогда споткнулся об то, что нужные директивы в JunOS появились только в 20-й версии прошивки, которую мой древний SRX 100 физически "не потянет". С тех пор я приобрел на барахолке SRX 300 со свежей прошивкой и таки смог настроить то что хотел.
Что как минимум понадобится для всей этой уличной магии.
- Прошивка не ниже 20й.
- Хотя бы один "честный" IP-адрес, который не меняется со временем ("фиксированный").
- Какой-нибудь простенький PKI для выпуска клиентских и серверных X509-сертификатов (Easy-RSA подойдет).
Также следует помнить про ряд принципиальных ограничений, как со стороны сервера (Juniper), так и со стороны клиентов.
- В StrongSWAN под Android поддерживается только IKEv2 "на сертификатах" в режиме NAT-T (UDP:4500), даже если с двух сторон "прямые" IP-адреса.
- В Juniper не может быть двух ike dynamic gateway (т.е. когда IP клиента заранее неизвестен) на одном и том же local IP с разным набором криптоалгоритмов.
- Если выпускается N клиентских сертификатов с одним CA, при этом хочется кого-то пускать, кого-то нет (например, они используются не только для целей доступа к Juniper), то надо у них делать разные OU (или любое другое поле помимо CN), иначе Juniper не сможет их различать.
- ST-интерфейс на Juniper должен быть объявлен как multipoint и присутствовать в какой-либо security zone, а также ike-user-type = group-ike-id ("групповой" идентификатор).
Ниже куски из конфига для примера.
security {
ike {
policy IPSEC-SERVER {
description "This Juniper is a server for road-warriors";
proposals IPSEC-SERVER;
certificate {
local-certificate medved-2023;
trusted-ca ca-profile Staser_CA;
peer-certificate-type x509-signature;
}
}
gateway Worldwide {
ike-policy IPSEC-SERVER;
dynamic {
distinguished-name;
connections-limit 10;
ike-user-type group-ike-id;
}
local-identity distinguished-name;
external-interface ge-0/0/0.0;
local-address 1.2.3.4;
aaa {
access-profile ipsec-clients;
}
version v2-only;
}
}
ipsec {
vpn worldwide-server {
bind-interface st0.2;
df-bit copy;
ike {
gateway Worldwide;
proxy-identity {
local 0.0.0.0/0;
remote 0.0.0.0/0;
}
ipsec-policy aes256-gcm-3600;
}
}
}
}
interfaces {
st0 {
unit 2 {
description "WAN IPSec server";
multipoint;
family inet {
mtu 1438;
address 192.168.22.41/30;
}
}
}
}
access {
profile ipsec-clients {
authentication-order none;
address-assignment {
pool ipsec-clients;
}
}
address-assignment {
pool ipsec-clients {
family inet {
network 192.168.22.40/30;
range oneshot {
low 192.168.22.42;
high 192.168.22.42;
}
}
}
}
}
На что нужно обратить внимание.
- В gateway должен быть определен "local-address", без него отхватишь самых разных чудес. При этом в конфигурации не должно быть ещё одного dynamic с таким же local-address.
- Некоторые клиенты требуют, чтобы в AltName серверного сертификата обязательно был бы прописан корректный DNS или IP сервера.
- Перед началом тестирования обязательно убедиться, что свеженастроенный vpn в списке "show security ipsec inactive-tunnels" находится в статусе "Dynamic tunnel configuration is ready. Waiting for peer(s) to initiate negotation". Иначе можно впустую потратить ну о-о-о-очень много времени на отладку (примерно как я, да).
- Обязательно наличие директив "multipoint" и "ike-user-type group-ike-id", иначе не взлетит с совершенно неинформативными отлупами.
- Наличие директивы "authentication-order none" принципиально, т.к. в противном случае Juniper будет отбивать по неуспешной авторизации (некий аналог XAuth).
- В "address-assignment" нужно определить подсеть и диапазон раздаваемых подключающимся клиентам IP-адресов. В моем примере клиент может быть только один.