Моя первоначальная попытка состояла в том, чтобы попытаться использовать совместное использование подключения к Интернету и выделить машину для внешнего интерфейса Linux (просто перенаправить множество портов), но совместное использование подключения, похоже, не работает при подключении к лазурной VPN (я пробовал Windows 10, и пока win2008R2).
Я также не могу найти программное обеспечение VPN для Linux, которое поддерживает необходимые протоколы.
Можно подключить Linux к Azure P2S с помощью strongSwan (IKEv2). Microsoft просто не заморачивается этим вопросом и настаивает на прохождении курса «P2S для Linux не поддерживается» (именно на это мне ответили в билетах поддержки). Вот как вы можете настроить IKEv2 на основе аутентификации сертификатов.
Вот необходимые пакеты для Ubuntu:
apt-get install strongswan-ikev2 strongswan-plugin-eap-tls
# in Ubuntu 16.04 install libstrongswan-standard-plugins for p12 keypair container support
apt-get install libstrongswan-standard-plugins
Если вы установите libstrongswan-extra-plugins
пакет в Ubuntu 16.04, он сломает strongSwan. Этот пакет содержит af-alg
, ctr
и gcrypt
плагины, и они конфликтуют с openssl
плагин. В этом случае необходимо либо удалить libstrongswan-standard-plugins
пакет, содержащий openssl
плагин или отключить openssl
плагин:
sudo sed -i 's/\sload =.*/ load = no/g' /etc/strongswan.d/charon/openssl.conf
или af-alg
, ctr
и gcrypt
плагины:
sudo sed -i 's/\sload =.*/ load = no/g' /etc/strongswan.d/charon/{af-alg,ctr,gcrypt}.conf
Сначала вам нужно создать свой собственный CA, затем необходимо сгенерировать сертификат пользователя с X509v3 Альтернативное имя субъекта (SAN) расширение (strongSwan FAQ), которое должно соответствовать общему имени субъекта сертификата (CN). Т.е. сертификат с CN=client
тема должна содержать DNS:client
SAN. Это позволит вам указать идентификатор EAP без CN=
префикс в strongSwan. По умолчанию strongSwan передает полную тему сертификата как удостоверение EAP, но шлюз Azure VPN не поддерживает это. Вы можете узнать больше об истории CN vs SAN: http://unmitigatedrisk.com/?p=381.
# Generate CA
ipsec pki --gen --outform pem > caKey.pem
ipsec pki --self --in caKey.pem --dn "CN=VPN CA" --ca --outform pem > caCert.pem
# Print CA certificate in base64 format, supported by Azure portal. Will be used later in this document.
openssl x509 -in caCert.pem -outform der | base64 -w0 ; echo
# Generate user's certificate and put it into p12 bundle.
export PASSWORD="password"
export USERNAME="client"
ipsec pki --gen --outform pem > "${USERNAME}Key.pem"
ipsec pki --pub --in "${USERNAME}Key.pem" | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --dn "CN=${USERNAME}" --san "${USERNAME}" --flag clientAuth --outform pem > "${USERNAME}Cert.pem"
# Generate p12 bundle
openssl pkcs12 -in "${USERNAME}Cert.pem" -inkey "${USERNAME}Key.pem" -certfile caCert.pem -export -out "${USERNAME}.p12" -password "pass:${PASSWORD}"
Затем откройте портал Azure, найдите свой «Виртуальный сетевой шлюз» и на его Конфигурация точка-сеть страница в Корневые сертификаты вставьте раздел CA, закодированный в base64, напечатанный выше
найти Скачать клиент VPN на странице конфигурации "точка-сеть" шлюза, затем разархивируйте VpnServerRoot.cer
ЦС из скаченного ZIP-архива:
sudo unzip -j downloaded.zip Generic/VpnServerRoot.cer -d /etc/ipsec.d/cacerts
Вы можете проверить это, используя команду ниже:
openssl x509 -inform der -in /etc/ipsec.d/cacerts/VpnServerRoot.cer -text -noout
Затем извлеките DNS сервера VPN:
$ unzip -p downloaded.zip Generic/VpnSettings.xml | grep VpnServer
<VpnServer>azuregateway-00112233-4455-6677-8899-aabbccddeeff-aabbccddeeff.cloudapp.net</VpnServer>
Используйте значение VpnServer для right
ценность и для rightid
значение с префиксом %
в ipsec.conf
ниже.
Затем скопируйте пакет p12 пользователя в соответствующий каталог:
sudo cp client.p12 /etc/ipsec.d/private/
Используйте следующее /etc/ipsec.conf
конфигурация:
config setup
conn azure
keyexchange=ikev2
type=tunnel
leftfirewall=yes
left=%any
leftauth=eap-tls
leftid=%client # use the DNS alternative name prefixed with the %
right=azuregateway-00112233-4455-6677-8899-aabbccddeeff-aabbccddeeff.cloudapp.net # Azure VPN gateway address
rightid=%azuregateway-00112233-4455-6677-8899-aabbccddeeff-aabbccddeeff.cloudapp.net # Azure VPN gateway address, prefixed with %
rightsubnet=0.0.0.0/0
leftsourceip=%config
auto=add
и /etc/ipsec.secrets
содержание:
: P12 client.p12 'password' # key filename inside /etc/ipsec.d/private directory
Затем перезапустите ipsec, чтобы перечитать конфигурацию и запустить туннель:
sudo ipsec restart
sudo ipsec up azure
Клиент IPsec VPN может испытывать проблемы с подключением из-за высоких значений MTU / MSS и IKE фрагментация. Чтобы решить эту проблему, вы должны явно установить значение 1350 для MTU / MSS вне kernel-netlink
сильный charon
конфигурация (эта конфигурация работает только в версии strongSwan> = 5.2.1). Установить mtu
и mss
ценности внутри /etc/strongswan.d/charon/kernel-netlink.conf
Файл конфигурации:
mss = 1350
mtu = 1350
и перезапустите туннель:
sudo ipsec restart
sudo ipsec up azure
Да, OpenVPN сделал свое дело. Поскольку иностранные пакеты не могут проходить через сеть Azure, я не смог использовать OpenVPN в качестве шлюза на стороне Azure в традиционном смысле. Я установил клиент OpenVPN на каждую виртуальную машину и использовал функцию клиент-клиент в OpenVPN, чтобы все они могли видеть друг друга. Несмотря на то, что он не оптимален, он работает в нашей тестовой сети, пока мы ожидаем подключения IPsec ExpressRoute к Azure. Самое приятное, что для этого требуется только порт 443 по TCP, который без проблем проходит через все.
совместное использование подключения, похоже, не работает при подключении к лазурному VPN (до сих пор я пробовал Windows 10 и win2008R2).
Мы не можем использовать Azure P2S VPN таким образом.
ICS направляет пакеты TCP / IP из небольшой локальной сети в Интернет. ICS сопоставляет отдельные IP-адреса локальных компьютеров с неиспользуемыми номерами портов в стеке TCP / IP. Из-за характера NAT, IP-адреса на локальном компьютере не видны в Интернете. Все пакеты, исходящие или входящие в локальную сеть, отправляются с или на IP-адрес внешнего адаптера на главном компьютере ICS.
Azure P2S VPN, используемый для создания безопасного подключения к виртуальной сети Azure с отдельного клиентского компьютера. После подключения к Azure VPN хост-компьютер ICS получит IP-адреса из пула адресов VPN-клиентов типа «точка-сеть», указанного в конфигурации. Результаты должны быть примерно такими:
PPP adapter VNet1:
Connection-specific DNS Suffix .:
Description.....................: VNet1
Physical Address................:
DHCP Enabled....................: No
Autoconfiguration Enabled.......: Yes
IPv4 Address....................: 172.16.201.3(Preferred)
Subnet Mask.....................: 255.255.255.255
Default Gateway.................:
NetBIOS over Tcpip..............: Enabled
Хост-компьютер ICS взаимодействует с Azure через IP-адрес пула адресов клиента VPN, но хост-компьютер ICS не могу используйте этот IP-адрес для совместного использования сети, поэтому мы не можем использовать Azure P2S VPN таким образом.
Если вы хотите, чтобы все компьютеры подключались к Azure, мы можем подключить их с помощью P2S VPN, создать на них VPN-подключения.
Я также не могу найти программное обеспечение VPN для Linux, которое поддерживает необходимые протоколы.
На данный момент поддержка Azure P2S VPN ограничена. только к Windows Операционная система.
Если вы хотите подключиться к виртуальной сети Azure через Linux, мы можем использовать некоторое программное обеспечение на базе Linux, здесь блог о том, как подключить виртуальную сеть Azure через Linux, см. Это.