Hoe u een tweede VPN-client op een Mac test zonder de eerste te verliezen
Een tweede client verandert routes, DNS en extensies, niet alleen een knop. Leg de basislijn vast, wijzig één pad tegelijk en herstel de oorspronkelijke werkstroom.
U installeert de tweede client om hem te vergelijken, en de eerste werkt niet meer. Er is niets verwijderd, en beide toepassingen zijn nog steeds geïnstalleerd. Wat veranderd is, zit eronder: een systeemextensie, een DNS-instelling of een standaardroute, en de twee clients zijn het er nu niet over eens wie de eigenaar is. De installatie is niet het riskante deel; het riskante deel is beide draaien zonder vastgelegde basislijn om naar terug te keren.
Het symptoom: de werkende opstelling stopt na de tweede installatie
Moderne macOS VPN-clients leveren vaak een netwerkextensie in plaats van een interface van oude stijl. Het installeren van een kan om goedkeuring vragen, een configuratieprofiel toevoegen of een systeemextensie registreren die het verkeer beïnvloedt voordat er ook maar een verbinding tot stand komt. De extensie wordt geladen voordat het app-venster verschijnt, waardoor de oorspronkelijke client kan falen terwijl de nieuwe werkloos blijft.
Als de oorspronkelijke client daarna geen verbinding kan maken, of verbinding maakt en niets oplost, is de nieuwe extensie de eerste verdachte. Dat is geen bewijs van een conflict, maar daar begint het onderzoek. Controleer vervolgens de lijst met extensies en de geïnstalleerde configuratieprofielen, niet alleen de map met toepassingen.
Leg de basislijn vast voordat u iets installeert
Schrijf op wat nu werkt: het resultaat van de toepassing, de clientversie, het eindpunt waarmee hij verbindt, en eventuele uitsluitingen per app of voor de gedeelde tunnel. Bewaar het oorspronkelijke profiel via het beveiligde proces dat de client ondersteunt, niet door bestanden uit een toepassingspakket te kopiëren.
scutil --dns | head -40
netstat -rn | head -30
ifconfig | grep -E "^(utun|ipsec)"
Leg die drie uitvoer vast terwijl de werkende client is verbonden. Ze geven u de status van de resolver, de routetabel en de interfacelijst die een werkende opstelling oplevert, en dat is precies wat u later nodig hebt voor de vergelijking. Als de Mac door een werkgever wordt beheerd, bevestig dan vooraf dat de vergelijking is toegestaan, want een automatische werkverbinding kan tijdens de test opnieuw actief worden en het resultaat vertegenwoordigt dan geen van beide clients alleen. Bewaar de drie uitvoer naast de profielnotitie zodat de latere vergelijking een referentie heeft.
Wijzig één actief pad tegelijk
Stop de oorspronkelijke verbinding met de normale bediening en start daarna het alternatief. Twee gelijktijdig verbonden clients geven een resultaat dat de combinatie beschrijft, niet een van de producten. Houd het eindpunt en de taak vergelijkbaar als de diensten dat toestaan, want een snellere download via een andere server vergelijkt twee verbindingsopties en niet twee toepassingen.
Als de nieuwe client faalt, bewaar dan de eerste fout voordat u iets anders wijzigt. De eerste fout noemt meestal de fase, en een tweede poging na een instellingswijziging meldt vaak iets minder bruikbaars.
Vergelijk DNS, routes en de app, niet alleen snelheid
Voer dezelfde drie opdrachten uit met de nieuwe client verbonden en vergelijk ze regel voor regel. Een resolver die elders heen wijst, of een routetabel zonder het privé-subnet, verklaart de meeste gedragsverschillen voordat u naar de doorvoer kijkt. Test daarna de eigenlijke toepassing met dezelfde taak, want een client die snel verbindt en een interne naam niet oplost, heeft de vergelijking niet gewonnen ook al ziet het statusvenster er beter uit.
Let op welke interface het verkeer gebruikte. Op macOS is de naam van de tunnelinterface geen betrouwbare aanwijzing voor welke client de route bezit, dus combineer de interfacelijst met de routetabel in plaats van er maar één te lezen. Als er twee utun-interfaces bestaan, is degene met een overeenkomende route en een resolver-vermelding degene die uw verkeer draagt. Gokken op de naam is hoe de verkeerde interface de schuld krijgt, want de interface die bestaat is niet altijd degene die verkeer draagt.
Lees de drie uitvoer in plaats van ze alleen te scannen. In de resolver-dump toont een naamserver die aan een utun-interface is gekoppeld welke client hem heeft geïnstalleerd; in de routetabel noemt de standaardroute de interface die verkeer draagt; in de interfacelijst betekent een tweede utun-apparaat dat er een tweede tunnel is gemaakt. Die drie regels scheiden, vergeleken met de basislijn, een herstelde opstelling van een waarin beide clients nog steeds concurreren.
Herstel en verwijder daarna netjes
Keer terug via de eigen werkstroom van de oorspronkelijke client en bevestig dat de basislijnuitvoer overeenkomt met wat u hebt vastgelegd. Als de resolver of de routetabel niet herstelt, stop dan en los dat op voordat u iets anders verwijdert. Verwijder de ongebruikte opstelling via het onderdeel dat er eigenaar van is: het verwijderprogramma van de client, het profiel of de instellingen van de systeemextensie.
Sluit af door uw notities bij te werken met de geteste versie, het gebruikte eindpunt en het resultaat voor elk. Een half jaar later is die vastlegging het verschil tussen een beslissing en een gerucht.