Den anden VPN-klient ødelagde den første: find den delte ressource

I går virkede den oprindelige klient. I dag kræver nykommeren en forbindelse, mens den ældre profil stopper på et trin, den før kom forbi uden klage. Legitimationsoplysninger er sjældent involveret, og gatewayen er normalt uskyldig. Det, der har ændret sig, er, at to VPN-stakke nu vil have den samme eksklusive ressource, og reparationen afhænger af at navngive den. Gå lagene igennem i stedet for at geninstallere begge.

Gå de fire lag igennem i rækkefølge

Et VPN-produkt har brug for fire ressourcer, der kan kollidere: en baggrundstjeneste, som ofte nægter at køre to gange, en fast port, en virtuel adapter eller kernefilter, som ser trafik, før routingtabellen gør, og retten til at installere ruter foran standardruten. At vide, hvilken der gav efter, gør en vag konflikt til et enkelt spørgsmål med et testbart svar.

Knyt symptomet til et lag, før du rører noget. En klient, der ikke starter, peger på tjenesten; en, der starter og aldrig forhandler, peger på porten; en, der forbinder, mens den anden mister al forbindelse, peger på filteret eller på standardruten. Skriv den kobling ned, fordi den sparer en time med at geninstallere programmer i håb.

Begynd ved tjenesten, der ikke vil køre to gange

På Windows er en virksomhedsklient normalt mere end en tunnel, fordi den installerer en tjeneste, en filterdriver og nogle gange en legitimationsudbyder sammen med profilen. Notér, hvilke tjenester der kører før ændringen og igen efter, og sammenlign de to lister i stedet for at genstarte, indtil noget virker. Tjenester kan også udelukke hinanden via afhængigheder, hvor start af den ene stopper den anden, og samme mønster ses på macOS med launchd-job og en delt daemon. En klient, der starter og afslutter inden for sekunder, rapporterer ejerskab frem for konfiguration.

Læs tjenestens tilstand og dens log, før du læser profilen. En tjeneste, der startede og stoppede inden for samme minut, er det mønster, du skal lede efter, og dens egen hændelseslog navngiver den afhængighed, der fortrængte den. En profil kan ikke reparere en proces, der ikke kører, og tid brugt på at redigere den er tid, der ikke bruges på den faktiske konflikt.

Spørg så, hvem der ejer porten

Portejerskab er det tydeligste bevis, du får, fordi en bind-fejl navngiver konflikten direkte. To IKE-implementeringer kan ikke begge svare på samme lokale adresse og UDP-port, og ingen mængde gentagelser ændrer det.

Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress,LocalPort,OwningProcess
netstat -ano | findstr :500
sudo lsof -nP -iUDP:500
ss -lunp | grep -E ':500|:4500'

Uanset hvilken linje der passer til din platform, er svaret, du vil have, en proces og den tjeneste, der skabte den. Hvis lytteren er den indbyggede IKE-tjeneste, er den anden klient indtrængeren; hvis det er en leverandøragent, er den indbyggede klient det. Beslut, hvilken der må starte ved login, og deaktiver den andens autostart i stedet for at dræbe den hver session.

Filterdriveren ligger under dine ruter

En netværksfilterdriver opsnapper trafik mellem adapteren og protokolstakken, så den kan omskrive eller blokere pakker, uanset hvad routingtabellen siger. Det er sådan en rute, der ser korrekt ud, bliver ignoreret, og hvorfor en vellykket ping kan ligge ved siden af en browser, der ikke kan indlæse noget.

Leverandørkomponenter binder sig også til bestemte forbindelser. Et ældre filter bundet til én adapter kan forhindre en ellers korrekt profil i at fuldføre sit håndtryk, og at løsne den komponent fra adapterens egenskaber er snævrere og mere reversibelt end at fjerne produktet helt. Da bindingen er per forbindelse, sammenlign adapterne i stedet for hele stakken.

Beslut, hvilket produkt der ejer opstarten, og notér det

Sameksistens er kun realistisk, når de to klienter efter design besætter forskellige lag, som en IPsec-stak ved siden af en proxy, der kun håndterer applikationstrafik. Hvor begge vil have samme port, samme filterlag eller retten til at udbyde en standardrute, vil de blive ved med at skiftes, og hver fejl vil se ud som en ny fejl.

Vælg ejeren bevidst. Former, der overlever en genstart, omfatter at køre den anden klient i en virtuel maskine, holde den på dedikeret hardware eller standardisere på én klient, der taler begge protokoller. At deaktivere taberens autostart og tjeneste er en mindre ændring end at genopbygge routingtabellen efter hver start, og det rulles tilbage med én ændring af indstillingerne.