Vraag Hoe de standaard Mac OSX routeringstabel opnieuw te laden zonder opnieuw op te starten


Groeten,

ik gebruik vpnc voor een VPN-client. Ik doe ook een paar lastige dingen met route om ervoor te zorgen dat ik nog steeds toegang heb tot mijn lokale netwerk, enz. enz. (de bijzonderheden hier zijn niet erg belangrijk).

Soms krijg ik de routetafel zo opgevijzeld dat ik die krijg ping: sendto: Network is unreachable voor URL's die anders zouden moeten oplossen.

Momenteel, als ik Mac OS X opnieuw start, is alles weer normaal. Wat ik zou willen doen is de routeringstabellen resetten naar de "standaard" (bijvoorbeeld wat het is ingesteld bij het opstarten) zonder een heel systeem herstart.

Ik denk dat stap 1 is route flush (om alle routes te verwijderen). En stap 2 moet alle standaardroutes opnieuw laden.

Eventuele gedachten over hoe dit te doen? (bijvoorbeeld wat is stap 2?)

BEWERK Ook merk ik dat een ander symptoom is traceroute mislukt ook op het adres in kwestie. Bijvoorbeeld:

traceroute the.good.dns.name

traceroute: bind: Can't assign requested address


58
2017-10-26 15:43


oorsprong




antwoorden:


Je moet de routes doorspoelen. Gebruik route -n flush meerdere malen . Voeg daarna uw routes toe met routeaanvulling.


51
2017-11-02 09:51



Ik heb dit veranderd in het geaccepteerde antwoord. Het werkt! ik deed route -n flush meerdere keren, dan heb ik mijn netwerk opnieuw gestart via de systeemvoorkeuren. Het kostte me maar een jaar om terug te komen en dit uit te zoeken :) - Nate Murray
Dit loste een soortgelijk probleem op met de Sonicwall's Aventail Connect VPN-client die ik vooral gevoelig vind voor "Kan opgevraagde adres niet toewijzen" -fouten, vooral bij het schakelen tussen draadloze netwerken. Nu heb ik een manier om dit op te lossen, zonder een stroomcyclus te vermijden. Bedankt! - Alan Donnelly


Ik liep dit probleem tegen het lijf terwijl ik een OpenVPN-server thuis gebruikte en ermee verbinding maakte met de Tunnelblick-toepassing op Mac.

Wat er aan mijn kant gebeurde, was dat een route met mijn thuis-IP als bestemming en een verkeerde gateway overbleef na het loskoppelen van de VPN. Het verwijderen van deze route loste het probleem eenvoudig op

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

Voorbeeld: ik ben op school en na een nieuwe computer opstart ik verbinding met een draadloos netwerk. Ik maak verbinding met mijn Home OpenVPN-server met Tunnelblick.

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

Ik verbreek de verbinding met de VPN-server. Ik verander draadloze netwerken. Dit verandert mijn standaardgateway.

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

Ik kan in geen geval verbinding maken met mijn thuisnetwerk (VPN, ping, wat dan ook) nadat dit is gebeurd. Als ik dan gewoon de route verwijder:

$ 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

Het werkt goed.

Er kan een probleem zijn met hoe de OpenVPN-server / client is geconfigureerd die dit verlaat (en ik zou graag willen weten wat dat is), maar ik installeerde een Tunnelblick script om de verbinding te verbreken dat deze routeverwijdering automatiseert.


15
2018-04-17 17:46



Ik heb hier eigenlijk een soortgelijk probleem. Heel vervelend. - Tom Busby
Ik kom hetzelfde probleem tegen, zelfs met het voorbeeld van een ovpn-script. De enige oplossing die ik heb gevonden is hetzelfde als OP, bij het verwijderen van de route in een script dat de verbinding verbreekt: / - jklp
Is er een manier om dit script bij elke verbreking automatisch uit te voeren? - Whitecat
@Whitecat Ja! Bekijk dit: superuser.com/a/1305361 - Elad Nava


Eerst heb je een route nodig voor je netwerkinterface. Als de VPN is losgekoppeld, haalt u gewoon uw netwerkinterface naar beneden en brengt u hem terug met ifconfig. Gebruik vervolgens de routecommand om je standaard GW in te bouwen. Dus zoiets als:

ifconfig en0 down

ifconfig en0 up

route add <ip address> default


9
2017-10-26 20:34



Ja, maar hoe weet Mac OS X wat het IP-adres van de standaardroute is? Wat ik echt zou willen zien is hoe Mac OS X het opstartproces doet en precies hetzelfde doet. - Nate Murray
...? Het haalt het van DHCP ... - Jordan Eunson


Ik kwam dezelfde kwestie tegen als @Sean (ik gebruik ook OS X), in die zin dat toen ik overschakelde tussen thuis- en werknetwerken, de standaardroute niet werd verwijderd.

Voor de volledigheid, wanneer ik thuis verbinding maak met mijn VPN en de volgende opdracht uitvoert, wordt de standaardgateway weergegeven zoals hieronder

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

En toen ik de verbinding verbrak, zou de [home-ip] gateway er nog steeds zijn. Toen ik verbinding maakte met mijn werknetwerk, kon ik helemaal geen verbinding maken met internet en kwam ik hetzelfde probleem tegen als bij OP

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

Ik zou dan de route handmatig moeten verwijderen met

$ sudo route -n delete [home-ip]

In eerste instantie heb ik de "route -n verwijderen" in a gezet post-disconnect.sh script, maar dat was een beetje rommelig, maar in plaats daarvan vond ik deze link

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

Blijkbaar is de reden het gevolg van het instellen van het volgende in mijn .ovpn het dossier

user nobody
group nogroup

Dit betekent dat de route is ingesteld als root, maar wanneer de verbinding wordt verbroken, is de gebruiker niet langer root, dus de route kan niet worden verwijderd.

Een commentaar geven op deze 2 regels in mijn .ovpn bestand verholpen het probleem, zonder een te gebruiken post-disconnect.sh.


5
2017-10-05 23:29



Bedankt, dit werkte ook voor mij. Het is jammer dat de link naar de Google-code niet meer werkt. - Toby
Ik heb geprobeerd je suggestie te gebruiken, het probleem is dat wanneer ik verbinding maak met de VPN, het de configuratiebestanden ergens vandaan haalt en mijn wijzigingen overschrijft. Het krijgt ze niet van de server, voor zover ik kan vertellen, omdat wanneer ik die bestanden verander het het probleem niet oplost. Is er een locatie aan de clientzijde waar ik deze bestanden kan vinden en ze kan vernietigen / wijzigen zodat mijn wijzigingen behouden blijven? - Finncent Price
Ik maakte de triviale fout van verwarrend ~ / Bibliotheek met / Bibliotheek. Oops! Voor iedereen die dit leest, wil je het bestand wijzigen in ~ / Bibliotheek / Application Support / Tunnelblick / Configuraties / <vpnname> .tblk / Contents / Resources - Finncent Price