Den andre VPN-klienten ødela den første: finn den delte ressursen

I går virket den opprinnelige klienten. I dag krever nykommeren en tilkobling, mens den eldre profilen stopper på et trinn den før kom forbi uten klage. Påloggingsinformasjon er sjelden involvert, og gatewayen er vanligvis uskyldig. Det som har endret seg, er at to VPN-stakker nå vil ha den samme eksklusive ressursen, og reparasjonen avhenger av å navngi den. Gå gjennom lagene i stedet for å installere begge på nytt.

Gå gjennom de fire lagene i rekkefølge

Et VPN-produkt trenger fire ressurser som kan kollidere: en bakgrunnstjeneste som ofte nekter å kjøre to ganger, en fast port, en virtuell adapter eller kjernefilter som ser trafikk før rutetabellen, og retten til å installere ruter foran standardruten. Å vite hvilken som ga etter gjør en vag konflikt om til ett spørsmål med et testbart svar.

Koble symptomet til et lag før du rører noe. En klient som ikke starter, peker på tjenesten; en som starter og aldri forhandler, peker på porten; en som kobler til mens den andre mister all tilkobling, peker på filteret eller på standardruten. Skriv ned den koblingen, fordi den sparer en time med å installere programmer på nytt i håp.

Begynn med tjenesten som ikke vil kjøre to ganger

På Windows er en bedriftsklient vanligvis mer enn en tunnel, fordi den installerer en tjeneste, en filterdriver og noen ganger en påloggingsinformasjonsleverandør ved siden av profilen. Noter hvilke tjenester som kjører før endringen og igjen etter, og sammenlign de to listene i stedet for å starte på nytt til noe virker. Tjenester kan også utelukke hverandre via avhengigheter, der start av én stopper en annen, og samme mønster vises på macOS med launchd-jobber og en delt daemon. En klient som starter og avslutter innen sekunder, rapporterer eierskap og ikke konfigurasjon.

Les tjenestens tilstand og loggen dens før du leser profilen. En tjeneste som startet og stoppet innen samme minutt, er mønsteret du skal se etter, og dens egen hendelseslogg navngir avhengigheten som fortrengte den. En profil kan ikke reparere en prosess som ikke kjører, og tid brukt på å redigere den er tid som ikke brukes på den faktiske konflikten.

Spør så hvem som eier porten

Porteierskap er det tydeligste beviset du får, fordi en bindingsfeil navngir konflikten direkte. To IKE-implementasjoner kan ikke begge svare på samme lokale adresse og UDP-port, og ingen mengde gjentakelser endrer 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'

Uansett hvilken linje som passer plattformen din, er svaret du vil ha en prosess og tjenesten som skapte den. Hvis lytteren er den innebygde IKE-tjenesten, er den andre klienten inntrengeren; hvis det er en leverandøragent, er den innebygde klienten det. Bestem hvilken som får starte ved innlogging, og deaktiver den andres autostart i stedet for å drepe den hver økt.

Filterdriveren ligger under rutene dine

En nettverksfilterdriver fanger trafikk mellom adapteren og protokollstakken, så den kan skrive om eller blokkere pakker uansett hva rutetabellen sier. Slik blir en rute som ser riktig ut ignorert, og derfor kan en vellykket ping ligge ved siden av en nettleser som ikke kan laste noe.

Leverandørkomponenter binder seg også til bestemte tilkoblinger. Et eldre filter bundet til én adapter kan hindre en ellers korrekt profil i å fullføre håndtrykket, og å løsne komponenten fra adapterens egenskaper er smalere og mer reversibelt enn å fjerne produktet helt. Siden bindingen er per tilkobling, sammenlign adapterne i stedet for hele stakken.

Bestem hvilket produkt som eier oppstarten, og noter det

Sameksistens er bare realistisk når de to klientene etter design okkuperer ulike lag, som en IPsec-stakk ved siden av en proxy som bare håndterer applikasjonstrafikk. Der begge vil ha samme port, samme filterlag eller retten til å publisere en standardrute, vil de fortsette å bytte på det, og hver feil vil se ut som en ny feil.

Velg eieren med vilje. Former som overlever en omstart inkluderer å kjøre den andre klienten i en virtuell maskin, holde den på dedikert maskinvare, eller standardisere på én klient som snakker begge protokollene. Å deaktivere taperens autostart og tjeneste er en mindre endring enn å bygge rutetabellen på nytt etter hver start, og det reverseres med én innstilling.