VPN-route controleren op macOS: route get zonder iets te wijzigen

Een gebruiker bereikt het intranet op het kantoornetwerk en niet via de tunnel, terwijl Instellingen de VPN nog steeds als verbonden toont. De routetabel op dat moment bewerken riskeert de externe sessie te verbreken die u gebruikt om te diagnosticeren. Vraag in plaats daarvan de kernel welk pad hij voor de mislukkende host zou kiezen. Het macOS-hulpprogramma route heeft een get-bewerking die precies dat voor één bestemming beantwoordt, zonder iets te wijzigen.

Vraag de mislukkende host op, niet de standaardroute

Een schermafbeelding van de standaardroute zegt op een moderne Mac heel weinig, omdat een specifiekere bestemming of een beperkt beleid kan overrulen wat de standaardroute lijkt te zeggen. De tunnel kan actief zijn, de standaardroute kan er correct uitzien, en de ene host die u nodig hebt kan toch elders worden gerouteerd. Vraag het adres op dat mislukt en laat de kernel het gekozen pad benoemen.

De vorm is route -n get gevolgd door het adres: route -n get 203.0.113.10, waarbij het documentatieadres voor uw doel staat. Gebruik de geautoriseerde bestemming en de bijbehorende adresfamilie, want een IPv4-antwoord zegt niets over een bron die alleen IPv6 is. De documentatie van het route-hulpprogramma beschrijft de get-bewerking en de velden die zij afdrukt.

Lees de interface en de gateway als bewijs

Voer de query uit voordat u de VPN verbindt en daarna opnieuw, en vergelijk de regels voor interface en gateway. Het verschil tussen die twee antwoorden is wat de tunnel werkelijk heeft gewijzigd, en het is veel nuttiger dan een volledige dump van de tabel. Als de interface in beide runs identiek is, was de route nooit het probleem en kunt u stoppen met naar routing te kijken.

Noteer de bestemming, de interface, de gateway en het tijdstip van de query voordat u een conclusie trekt. De uitvoer is bewijs, geen diagnose: dezelfde interface kan correct zijn voor de ene host en onjuist voor de andere wanneer een gesplitste tunnel in het spel is.

Een correcte route is geen werkend verzoek

Een route vertelt u welke interface de kernel zou gebruiken, niets meer. DNS, een hostfirewall en applicatieautorisatie staan allemaal boven die beslissing, en het verzoek kan mislukken nadat routing is geslaagd. Bewaar het exacte symptoom voordat u verdergaat, want "kan niet verbinden" en "verbindt maar geeft een fout terug" zijn verschillende onderzoeken met verschillende vervolgstappen. De resolver-weergave en de interface-weergave vullen de bestemmingsquery aan in plaats van haar te vervangen.

Een lijst van de routetabel heeft nog steeds een plaats: zo merkt u een onverwachte standaardroute op. Een resterende gewone standaardroute bewijst niet dat de VPN ongebruikt is, omdat specifiekere vermeldingen ervan winnen.

Houd het eindpunt en de bron gescheiden

Er zijn twee opzoekingen in het spel en ze beantwoorden verschillende vragen. Het eindpunt bereiken is een uiterlijke reis door het fysieke netwerk. De applicatie bereiken gebeurt in de tunnel, op een adres dat alleen aan de private kant bestaat. De twee verwarren levert de klassieke valse lus op, waarin het eindpunt via de tunnel gerouteerd lijkt te worden die het beëindigt. Vraag beide adressen afzonderlijk op, label elk resultaat, en de verwarring verdwijnt.

Prefix-overlap is het andere geval dat de moeite waard is om te kennen. Wanneer lokale en externe bereiken overlappen, beslist de langste prefix-overeenkomst, dus een overlappend lokaal subnet kan het externe adres dat u verwachtte overschaduwen. De private bestemming lijkt dan identiek aan een lokale, en de correctie hoort in het adresplan thuis en niet in de routetabel. De get-query toont welke interface heeft gewonnen, en dat is het feit dat u nodig hebt voordat u iets wijzigt.

Eerst lezen, later wijzigen

Houd route add en route delete buiten de eerste ronde. Op een Mac die u op afstand beheert, kan één onzorgvuldige tabelwijziging precies de weg terug naar de machine wegnemen, en blijft er niemand over die de diagnose kan afmaken. Bepaal welke route correct is, schrijf op hoe de wijziging wordt teruggedraaid, en voer haar pas dan uit. Een inspectie heeft zo'n staart niet.

Dezelfde voorzichtigheid geldt voor het legen van caches en het herstarten van netwerkdiensten als eerste stap, omdat beide het bewijs vernietigen dat u op het punt stond te lezen. Alleen-lezen-controles zijn goedkoop, herhaalbaar en veilig in elke volgorde. Maak ze de standaardstap, en grijp alleen naar een wijziging wanneer het bewijs erop wijst.