11 июля 2011 в 11:00

iPad/iPhone в поездке. Совпадение адресов VPN и общественной сети

На отдыхе случилась неприятная ситуация: адресное пространство сети гостиницы 192.168.1.0/24 (далее — домашняя сеть) совпало с адресным пространством рабочей сети (при этом подключаемый к VPN компьютер получает адрес из сети 192.168.100.0/24).
При подключении к рабочей VPN все внутренние рабочие ресурсы остаются недоступными, т.к. в этом случае для доступа к ним iPad/iPhone пытается использовать свой беспроводной интерфейс, а не интерфейс в сети VPN.
Под катом очевидное решение, которое, однако, может помочь кому-нибудь сэкономить немного времени на осознание проблемы.

Поскольку мы не можем прямо повлиять на правила маршрутизации для интерфейсов iPad/iPhone (может быть, кто-нибудь знает способ?), мы изменим маску нашей домашней сети.
Первое, что нам надо делать это запомнить полученный по DHCP адрес:



В нашем случае это 192.168.1.7. Теперь нам надо переключиться на статический адрес в настройках сети и задать маску сети 255.255.255.255. Это приведет к тому, что все пакеты, даже предназначенные для хостов в домашней сети (в нашем случае сети гостиницы), будут отправляться на VPN-интерфейс, если мы правильно укажем шлюз по умолчанию.

Для этого переключаемся на соответствующую закладку в настройках сети и вводим тот IP-адрес, который нам назначен через DHCP, маску 255.255.255.255 и шлюз по умолчанию (маршрутизатор) в нашей VPN.



Даже если адрес шлюза в VPN совпадает с адресом шлюза в домашней сети, пакеты будут уходить в VPN, т.к. VPN-интерфейс имеет меньшую метрику.
@querct
карма
9,0
рейтинг 0,0
Похожие публикации
Самое читаемое

Комментарии (29)

  • 0
    >имеет более высокий приоритет. (не уверен в правильности фразы про приоритет, может кто-то поправит).
    Метрика? >_<
    • 0
      Спасибо. Поправил.
    • +1
      Метрика здесь ннне при чем. Приоритет при выборе маршрута имеет more specific маршрут.
  • +3
    Простите, а как пересекаются 192.168.100.0/24 и 192.168.1.0/24?
    • –1
      Может в гостинице было /32?
      • –1
        192.168.1.0/24 — адресное пространство и гостиницы и куска рабочей сети, который, собственно, и был недоступен.
      • +1
        32 — это один адрес.
        • –2
          угу, нну ошибся.
    • 0
      Промахнулся с комментарием, ответил ниже.
  • –2
    192.168.100.0/24 — это подсеть для удаленных пользователей, а 192.168.1.0/24 — подсеть для различных внутренних ресурсов.
    • +1
      ну так. Это разные подсети — 24 бита это первых три октета, соответственно 192.168.100.XXX != 192.168.1.XXX
      • 0
        я вот тоже не пойму…
        может не /24, а /16?
        • 0
          Проблема была не в том, что совпадает адрес, выдаваемый удаленному пользователю в сети VPN и адрес в домашней сети, а в том, что некоторые ресурсы в рабочей сети были недоступны из-за совпадения их адресов с адресами, входящими в маску домашней сети (192.168.1.0/24).
          • +1
            Т.е. по VPN комп (iPad) получает адрес из пространства 192.168.100.0/24, а фактическое пространство удаленной сети — 192.168.1.0/24, как и рабочей; а далее уже шлюз VPN передает пакеты внутрь удаленной сети (как бы, принцип NAT'а)?
            • 0
              Да, в данном случае все именно так.
              Но даже если бы комп получал адрес сразу в сети 192.168.1.0/24, действия по выходу из ситуации были бы такими же.
              • +1
                Теперь все понятно, спасибо :)

                Это понятное дело. В вашем же случае, я не сразу понял, что к чему. Подумал, что все удаленное в той же сети, т.е. 192.168.100.0/24.
  • +11
    Хватило ума выбрать для VPN-адресов такой распространенный сегмент. Выбирать надо что-то зубодробительное, типа 10.37.239.0/24. И пихать клиенту маршруты до LAN организации с короткими масками (или вообще, на время сеанса переписывать def. gw на vpn), тогда никаких проблем не будет.
    • +2
      > Выбирать надо что-то зубодробительное, типа 10.37.239.0/24
      Меня аж перекосило, зубодробительнее некуда! :)
      • +2
        Смысл в том, чтобы не выбирать привычные многим (а потому используемые везде и всюду) 192.168.1-100.xxx или 10.10.10.ххх и прочие «привычные да красивые».
        Естественно, необходимо сдерживать свою фантазию рамками RFC1918.
        • 0
          Да, суть я понял и с ней согласен.
          Просто пример ваш понравился :)
          • +1
            Плоховат стал мой двоичный рандом-генератор, старею…
  • –1
    Сталкивался с этой проблемой, с тех пор внутренняя сеть у нас на 172.16.х.х. Пока не встречал пересечений ни с кем. Обычно используют или 192.168.х.х, или 10.х.х.х.
    • +1
      Внутреннюю сеть необязательно переделывать, более того, иногда это просто невозможно. Достаточно просто пушить vpn-пользователю специфичные маршруты до своей сети, в идеале — хостовые (/32) до каждого сервиса, к которому необходим доступ посредством VPN. Тогда трафик гарантированно пойдет куда нужно, даже если будет пересечение по суперсетям.
  • 0
    Вроде 172.16.0.0/12 подходит?
  • 0
    IP: 192.168.1.7
    MASK: 255.255.255.255
    GW: 192.168.1.1

    Оно же не должно работать впринципе, или я чего-то не знаю?
    • 0
      Если маршруты прописать то будет
      • 0
        Топик о том, что маршруты ручками прописать нельзя :)
        Возможно, маршрут до шлюза добавляется автоматически на беспроводной интерфейс.
        • 0
          я подозреваю, что он в таком раскладе использует default dev, а не default gw, то есть все пакеты кидает в девайс в надежде, что там кто-то поймает
          как это в яблочных OS не могу сказать, а в GNU/Linux вполне существуе route add default dev dev-name
  • 0
    А еще проще сделать на VPN GW Split tunnel ))) И все будет всегда бегать )
    И не факт что будет работать если роуты поменять ручками, ipsec это UPD конекция и если сменить шлюз то сессия должна рухнуть )

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.