У Microsoft есть технология, называемая VPN «точка-сеть». (ссылка1, ссылка2)
У меня есть следующие внутренние сети класса "A", определенные локально:
У меня определены следующие сети Azure:
Я хочу создать подсеть для исключительного использования Point to Site VPN
Когда я сделаю это на портале, VPN-клиент добавит маршрут по умолчанию для 10.0.0.0/8. Обоснование этого Microsoft содержится в RFC1918, и они отказывают мне в настройке этого маршрута. На мой взгляд, они явно неправильно понимают, что этот RFC не применяется в данном случае.
Когда я меняю маску сети на 168.192.1.0, применяется маршрут класса B. Это работает, но меня раздражает то, что мне приходится отклоняться от моего шаблона нумерации из-за неправильного толкования RFC службой поддержки Microsoft.
Их ответ:
Как указано в RFC 1918, адресное пространство должно быть диапазоном частных адресов, указанным в нотации CIDR 10.0.0.0/8, 172.16.0.0/12 или 192.168.0.0/16.
Обратите внимание, что следующие маршруты будут добавлены к клиенту, соответственно, для направления трафика с локальной машины в виртуальную сеть: 10.0.0.0/255.0.0.0, 172.16.0.0/255.255.0.0 или 192.168.0.0/255.255.255.0 . Это означает, что, например, вы не сможете связаться с другими адресами 10.0.0.0/8 в вашей локальной подсети, если вы указали 10.0.0.0/8 для адресного пространства вашего VPN-клиента.
Любое адресное пространство, которое вы выбрали для начала с 10.x.x.x, приведет к этой проблеме (а не только 10.0.0.0/8). Пакет клиента VPN будет рассматривать это адресное пространство VPN как класс A (маска подсети 255.0.0.0) независимо от того, как вы решите определить его в Azure (например, 10.1.0.0/24).
Поэтому мы всегда просим наших клиентов использовать диапазон 192.168.0.0/X при создании среды P2S и убедиться, что он не пересекается с какой-либо подсетью, которая может быть у них локально (откуда подключаются их клиенты P2S).
Вопрос