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

[link0ln]

>имеет более высокий приоритет. (не уверен в правильности фразы про приоритет, может кто-то поправит).
Метрика? >_<

[querct]

Спасибо. Поправил.

[wwk]

Метрика здесь ннне при чем. Приоритет при выборе маршрута имеет more specific маршрут.

[Obramko]

Простите, а как пересекаются 192.168.100.0/24 и 192.168.1.0/24?

[cst]

Может в гостинице было /32?

[querct]

192.168.1.0/24 — адресное пространство и гостиницы и куска рабочей сети, который, собственно, и был недоступен.

[alexxxst]

32 — это один адрес.

[cst]

угу, нну ошибся.

[querct]

Промахнулся с комментарием, ответил ниже.

[querct]

192.168.100.0/24 — это подсеть для удаленных пользователей, а 192.168.1.0/24 — подсеть для различных внутренних ресурсов.

[Antigluk]

ну так. Это разные подсети — 24 бита это первых три октета, соответственно 192.168.100.XXX != 192.168.1.XXX

[Angel2S2]

я вот тоже не пойму…
может не /24, а /16?

[querct]

Проблема была не в том, что совпадает адрес, выдаваемый удаленному пользователю в сети VPN и адрес в домашней сети, а в том, что некоторые ресурсы в рабочей сети были недоступны из-за совпадения их адресов с адресами, входящими в маску домашней сети (192.168.1.0/24).

[Angel2S2]

Т.е. по VPN комп (iPad) получает адрес из пространства 192.168.100.0/24, а фактическое пространство удаленной сети — 192.168.1.0/24, как и рабочей; а далее уже шлюз VPN передает пакеты внутрь удаленной сети (как бы, принцип NAT'а)?

[querct]

Да, в данном случае все именно так.
Но даже если бы комп получал адрес сразу в сети 192.168.1.0/24, действия по выходу из ситуации были бы такими же.

[Angel2S2]

Теперь все понятно, спасибо :)

Это понятное дело. В вашем же случае, я не сразу понял, что к чему. Подумал, что все удаленное в той же сети, т.е. 192.168.100.0/24.

[bondbig]

Хватило ума выбрать для VPN-адресов такой распространенный сегмент. Выбирать надо что-то зубодробительное, типа 10.37.239.0/24. И пихать клиенту маршруты до LAN организации с короткими масками (или вообще, на время сеанса переписывать def. gw на vpn), тогда никаких проблем не будет.

[nxs]

> Выбирать надо что-то зубодробительное, типа 10.37.239.0/24
Меня аж перекосило, зубодробительнее некуда! :)

[bondbig]

Смысл в том, чтобы не выбирать привычные многим (а потому используемые везде и всюду) 192.168.1-100.xxx или 10.10.10.ххх и прочие «привычные да красивые».
Естественно, необходимо сдерживать свою фантазию рамками RFC1918.

[nxs]

Да, суть я понял и с ней согласен.
Просто пример ваш понравился :)

[bondbig]

Плоховат стал мой двоичный рандом-генератор, старею…

[bondbig]

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

[EndUser]

Вроде 172.16.0.0/12 подходит?

[mrMendoza]

IP: 192.168.1.7
MASK: 255.255.255.255
GW: 192.168.1.1

Оно же не должно работать впринципе, или я чего-то не знаю?

[Antigluk]

Если маршруты прописать то будет

[mechmind]

Топик о том, что маршруты ручками прописать нельзя :)
Возможно, маршрут до шлюза добавляется автоматически на беспроводной интерфейс.

[ergil]

я подозреваю, что он в таком раскладе использует default dev, а не default gw, то есть все пакеты кидает в девайс в надежде, что там кто-то поймает
как это в яблочных OS не могу сказать, а в GNU/Linux вполне существуе route add default dev dev-name

[Alaniyatm]

А еще проще сделать на VPN GW Split tunnel ))) И все будет всегда бегать )
И не факт что будет работать если роуты поменять ручками, ipsec это UPD конекция и если сменить шлюз то сессия должна рухнуть )