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-интерфейс имеет меньшую метрику.
    Поделиться публикацией
    Никаких подозрительных скриптов, только релевантные баннеры. Не релевантные? Пиши на: adv@tmtm.ru с темой «Полундра»

    Зачем оно вам?
    Реклама
    Комментарии 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 конекция и если сменить шлюз то сессия должна рухнуть )

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