Jak ponownie załadować domyślną tabelę routingu Mac OSX bez ponownego uruchamiania

Pozdrowienia,

Używam vpncdla klienta VPN. Robię też pewne trudne rzeczy, routeaby upewnić się, że nadal mogę uzyskać dostęp do mojej sieci lokalnej itp. Itp. (Dane tutaj nie są bardzo ważne).

Czasami dostaję tablicę routingu, więc mam ping: sendto: Network is unreachableochotę znaleźć adresy URL, które w przeciwnym razie powinny zostać rozwiązane.

Obecnie, jeśli zrestartuję Mac OS X, wszystko wróci do normy. To, co chciałbym zrobić, to zresetować tabele routingu do „domyślnych” (np. Co to jest ustawione przy rozruchu) bez ponownego uruchamiania całego systemu.

Myślę, że krok 1 to route flush(usunięcie wszystkich tras). Krok 2 musi ponownie załadować wszystkie domyślne trasy.

Wszelkie przemyślenia, jak to zrobić? (np. co to jest krok 2?)

EDYCJA Również zauważam, że inny symptom tracerouterównież zawiedzie na danym adresie. Na przykład:

traceroute the.good.dns.name

traceroute: bind: Can't assign requested address

Musisz opróżnić trasy. Użyj trasy -n spłucz kilka razy. Następnie dodaj swoje trasy z dodaniem trasy.

Wystąpił ten problem podczas korzystania z domowego serwera OpenVPN i łączenia się z nim za pomocą aplikacji Tunnelblick na komputerze Mac.

Z mojego punktu widzenia działo się tak, że po rozłączeniu z VPN pozostała trasa z moim adresem IP jako miejscem docelowym i niepoprawna brama. Usunięcie tej trasy rozwiązało problem, po prostu

$ sudo route -n delete the.good.dns.name

Przykład: Jestem w szkole i po ponownym uruchomieniu komputera łączę się z siecią bezprzewodową. Łączę się z moim domowym serwerem OpenVPN za pomocą Tunnelblick.

$ netstat -nr
Destination                   Gateway
....
[home-ip]/32                  [school-default-gateway-1] ....
....

Odłączam się od serwera VPN. Zmieniam sieci bezprzewodowe. To zmienia moją domyślną bramę.

$ 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
...

Nie mogę w żadnym wypadku połączyć się z moją siecią domową (VPN, ping, cokolwiek) po tym zdarzeniu. Jeśli następnie usunę trasę:

$ 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

To działa dobrze.

Może występować problem ze sposobem skonfigurowania serwera / klienta OpenVPN, który to opuszcza (i chciałbym dowiedzieć się, co to jest), ale zainstalowałem skrypt po odłączeniu Tunnelblick, który automatyzuje usuwanie trasy.

Najpierw potrzebujesz trasy dla interfejsu sieciowego. Jeśli VPN jest odłączony, po prostu zdejmij interfejs sieciowy, a następnie uruchom go ponownie za pomocą ifconfig. Następnie użyj komendy route, aby zbudować domyślny gw. Więc coś takiego:

ifconfig en0 down

ifconfig en0 up

route add <ip address> default

Wystąpił taki sam problem jak w przypadku @Sean (korzystam również z systemu OS X), ponieważ podczas przełączania między siecią domową a służbową trasa domyślna nie była usuwana.

Dla kompletności, gdy połączę się z moją VPN w domu i uruchomię następujące polecenie, wyświetli się domyślna brama, jak poniżej

$ netstat -nr
Destination                   Gateway
...
[home-ip]/32                  [work-default-gateway-1]

A kiedy się rozłączę, brama [home-ip] nadal będzie dostępna. Kiedy łączyłem się z siecią służbową, nie mogłem w ogóle połączyć się z Internetem i napotkałem ten sam problem co OP

$ traceroute the.good.dns.name    
$ traceroute: bind: Can't assign requested address

Musiałbym wtedy ręcznie usunąć trasę za pomocą

$ sudo route -n delete [home-ip]

Początkowo umieściłem „route -n delete” w post-disconnect.shskrypcie, ale to było trochę niechlujne, więc zamiast tego znalazłem ten link

https://code.google.com/p/tunnelblick/issues/detail?id=177

Najwyraźniej przyczyną tego jest ustawienie następujących rzeczy w moim .ovpnpliku

user nobody
group nogroup

Co oznacza, że ​​trasa jest skonfigurowana jako root, ale po usunięciu połączenia użytkownik nie jest już rootem, więc trasy nie można usunąć.

Komentowanie tych 2 wierszy w moim .ovpnpliku naprawiło problem, bez konieczności używania post-disconnect.sh.