Den andra VPN-klienten förstörde den första: hitta den delade resursen

Igår fungerade den ursprungliga klienten. Idag kräver nykomlingen en anslutning medan den äldre profilen stannar vid ett steg som den förut passerade utan klagomål. Inloggningsuppgifter är sällan inblandade, och gatewayen är oftast oskyldig. Det som har ändrats är att två VPN-stackar nu vill ha samma exklusiva resurs, och reparationen beror på att namnge den. Gå igenom lagren istället för att installera om båda.

Gå igenom de fyra lagren i ordning

En VPN-produkt behöver fyra resurser som kan kollidera: en bakgrundstjänst som ofta vägrar köra två gånger, en fast port, en virtuell adapter eller kärnfilter som ser trafik före routingtabellen, och rätten att installera rutter framför standardrutten. Att veta vilken som gav vika gör en vag konflikt till en enda fråga med ett testbart svar.

Koppla symtomet till ett lager innan du rör något. En klient som inte startar pekar på tjänsten; en som startar och aldrig förhandlar pekar på porten; en som ansluter medan den andra tappar all anslutning pekar på filtret eller på standardrutten. Skriv ner den kopplingen, för den sparar en timme av att installera om program i hopp.

Börja med tjänsten som inte vill köra två gånger

På Windows är en företagsklient oftast mer än en tunnel, eftersom den installerar en tjänst, en filterdrivrutin och ibland en leverantör av inloggningsuppgifter vid sidan av profilen. Notera vilka tjänster som körs före ändringen och igen efter, och jämför sedan de två listorna istället för att starta om tills något fungerar. Tjänster kan också utesluta varandra via beroenden, där start av en stoppar en annan, och samma mönster syns på macOS med launchd-jobb och en delad daemon. En klient som startar och avslutar inom sekunder rapporterar ägarskap och inte konfiguration.

Läs tjänstens tillstånd och dess logg innan du läser profilen. En tjänst som startade och stoppade inom samma minut är mönstret att leta efter, och dess egen händelselogg namnger det beroende som trängde undan den. En profil kan inte reparera en process som inte körs, och tid som läggs på att redigera den är tid som inte läggs på den faktiska konflikten.

Fråga sedan vem som äger porten

Portägarskap är det tydligaste beviset du får, eftersom ett bindningsfel namnger konflikten direkt. Två IKE-implementationer kan inte båda svara på samma lokala adress och UDP-port, och ingen mängd upprepningar ändrar 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'

Vilken rad som än passar din plattform är svaret du vill ha en process och den tjänst som skapade den. Om lyssnaren är den inbyggda IKE-tjänsten är den andra klienten inkräktaren; om det är en leverantörsagent är den inbyggda klienten det. Bestäm vilken som får starta vid inloggning och inaktivera den andras autostart istället för att döda den varje session.

Filterdrivrutinen sitter under dina rutter

En nätverksfilterdrivrutin fångar trafik mellan adaptern och protokollstacken, så den kan skriva om eller blockera paket oavsett vad routingtabellen säger. Så ignoreras en rutt som ser korrekt ut, och därför kan en lyckad ping ligga bredvid en webbläsare som inte kan ladda något.

Leverantörskomponenter binder sig också till specifika anslutningar. Ett äldre filter bundet till en adapter kan hindra en i övrigt korrekt profil från att slutföra sitt handslag, och att lossa den komponenten från adapterns egenskaper är snävare och mer återställbart än att ta bort produkten helt. Eftersom bindningen gäller per anslutning, jämför adaptrarna istället för hela stacken.

Bestäm vilken produkt som äger starten och anteckna det

Samexistens är bara realistisk när de två klienterna enligt design ockuperar olika lager, som en IPsec-stack bredvid en proxy som bara hanterar applikationstrafik. Där båda vill ha samma port, samma filterlager eller rätten att publicera en standardrutt kommer de att fortsätta turas om, och varje fel kommer att se ut som ett nytt fel.

Välj ägaren medvetet. Former som överlever en omstart inkluderar att köra den andra klienten i en virtuell maskin, hålla den på dedikerad hårdvara, eller standardisera på en klient som talar båda protokollen. Att inaktivera förlorarens autostart och tjänst är en mindre ändring än att bygga om routingtabellen efter varje start, och det återställs med en enda inställningsändring.