Как перезагрузить таблицу маршрутизации Mac OSX по умолчанию без перезагрузки
Привет,
я использую vpnc для VPN-клиента. Я также делаю некоторые сложные вещи с route чтобы убедиться, что я все еще могу получить доступ к своей локальной сети и т. д. и т. д. (подробности здесь не очень важны).
Иногда я получаю таблицу маршрутизации так измученный, я получаю ping: sendto: Network is unreachable для URL, которые должны разрешить в противном случае.
В настоящее время, если я перезагружаю Mac OS X, тогда все возвращается к нормальной жизни. То, что я хотел бы сделать, это сбросить таблицы маршрутизации на "по умолчанию" (например, то, что установлено при загрузке) без перезагрузки всей системы.
Я думаю, что шаг 1 route flush (удалить все маршруты). И шаг 2 должен перезагрузить все маршруты по умолчанию.
Есть мысли о том, как это сделать? (например, что такое шаг 2?)
РЕДАКТИРОВАТЬ Кроме того, я заметил, что еще один симптом traceroute также не на указанном адресе. Например:
traceroute the.good.dns.name
traceroute: bind: Can't assign requested address
4 ответа
Вам необходимо промыть маршруты. Используйте route -n flush несколько раз. Затем добавьте ваши маршруты с маршрутом добавить.
Я столкнулся с этой проблемой при использовании домашнего сервера OpenVPN и подключении к нему с помощью приложения Tunnelblick на Mac.
Что происходило на моем конце, так это то, что маршрут с моим домашним IP-адресом в качестве пункта назначения и неправильным шлюзом становился остатком после отключения от VPN. Удаление этого маршрута решило проблему, просто
$ sudo route -n delete the.good.dns.name
Пример: я в школе и после новой загрузки компьютера подключаюсь к беспроводной сети. Я подключаюсь к своему домашнему серверу OpenVPN с Tunnelblick.
$ netstat -nr
Destination Gateway
....
[home-ip]/32 [school-default-gateway-1] ....
....
Я отключаюсь от VPN-сервера. Я меняю беспроводные сети. Это меняет мой шлюз по умолчанию.
$ netstat -nr
Destination Gateway
...
[home-ip]/32 [school-default-gateway-1] ...
...
$ ping [home-ip]
PING [home-ip]: 56 data bytes
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
Request timeout for icmp_seq 0
...
Я не могу ни при каких обстоятельствах подключиться к моей домашней сети (VPN, ping, что угодно) после того, как это произойдет. Если я тогда просто удалю маршрут:
$ sudo route -n delete [home-ip]
delete net [home-ip]
$ ping [home-ip]
PING [home-ip]: 56 data bytes
64 bytes from [home-ip]: icmp_seq=1 ttl=56 time=13.111 ms
Работает нормально.
Может быть проблема с настройкой сервера / клиента OpenVPN, которая оставляет это (и мне было бы интересно узнать, что это такое), но я установил скрипт пост-разъединения Tunnelblick, который автоматизирует удаление этого маршрута.
Сначала вам нужен маршрут для вашего сетевого интерфейса. Если VPN отключена, просто отключите сетевой интерфейс и снова включите его с помощью ifconfig. Затем используйте маршрут commnand, чтобы встроить gw по умолчанию. Так что-то вроде:
ifconfig en0 down
ifconfig en0 up
route add <ip address> default
Я столкнулся с той же проблемой, что и @Sean (я также использую OS X), потому что при переключении между домашней и рабочей сетями маршрут по умолчанию не удалялся.
Для полноты, когда я подключаюсь к своему VPN дома и запускаю следующую команду, он показывает шлюз по умолчанию, как показано ниже
$ netstat -nr
Destination Gateway
...
[home-ip]/32 [work-default-gateway-1]
И когда я отключился, шлюз [home-ip] все еще был бы там. Когда я подключался к своей рабочей сети, я вообще не мог подключиться к Интернету и столкнулся с той же проблемой, что и OP
$ traceroute the.good.dns.name
$ traceroute: bind: Can't assign requested address
Затем мне придется вручную удалить маршрут с
$ sudo route -n delete [home-ip]
Первоначально я положил "маршрут -n удалить" в post-disconnect.sh сценарий, но это было немного грязно, поэтому вместо этого я нашел эту ссылку
https://code.google.com/p/tunnelblick/issues/detail?id=177
Видимо, причина заключается в установке следующего в моем .ovpn файл
user nobody
group nogroup
Это означает, что маршрут настроен как root, но когда соединение разорвано, пользователь больше не является root, поэтому маршрут не может быть удален.
Комментируя эти 2 строки в моем .ovpn файл исправил проблему, не используя post-disconnect.sh,