Tweede VPN-client sloopte de eerste: vind de gedeelde bron

Gisteren werkte de oorspronkelijke client. Vandaag eist de nieuwkomer een verbinding terwijl het oudere profiel stopt bij een stap die het eerder zonder klagen passeerde. Inloggegevens zijn zelden betrokken, en de gateway is meestal onschuldig. Wat veranderd is, is dat twee VPN-stacks nu dezelfde exclusieve bron willen, en de reparatie hangt af van het benoemen ervan. Loop de lagen door in plaats van beide opnieuw te installeren.

Loop de vier lagen op volgorde door

Een VPN-product heeft vier bronnen nodig die kunnen botsen: een achtergronddienst die vaak weigert twee keer te draaien, een vaste poort, een virtuele adapter of kernelfilter die verkeer ziet voordat de routetabel dat doet, en het recht om routes voor de standaardroute te installeren. Weten welke heeft toegegeven maakt van een vage botsing één vraag met een testbaar antwoord.

Koppel het symptoom aan een laag voordat u iets aanraakt. Een client die niet start wijst op de dienst; een die start en nooit onderhandelt wijst op de poort; een die verbindt terwijl de andere alle connectiviteit verliest wijst op het filter of op de standaardroute. Schrijf die koppeling op, want ze bespaart een uur applicaties opnieuw installeren in de hoop.

Begin bij de dienst die niet twee keer draait

Op Windows is een bedrijfsclient meestal meer dan een tunnel, omdat hij naast het profiel een dienst, een filterstuurprogramma en soms een inloggegevensprovider installeert. Noteer welke diensten voor de wijziging draaien en opnieuw daarna, en vergelijk dan de twee lijsten in plaats van opnieuw op te starten tot iets werkt. Diensten kunnen elkaar ook via afhankelijkheden uitsluiten, waarbij het starten van de ene de andere stopt, en hetzelfde patroon verschijnt op macOS met launchd-taken en een gedeelde daemon. Een client die binnen seconden start en afsluit, meldt eigenaarschap en niet configuratie.

Lees de status van de dienst en het logboek voordat u het profiel leest. Een dienst die binnen dezelfde minuut startte en stopte is het patroon waarnaar u zoekt, en het eigen gebeurtenislogboek noemt de afhankelijkheid die hem verdrong. Een profiel kan een proces dat niet draait niet repareren, en tijd die aan het bewerken ervan wordt besteed is tijd die niet aan het echte conflict wordt besteed.

Vraag dan wie de poort bezit

Poortbezit is het duidelijkste bewijs dat u krijgt, omdat een bindfout het conflict ronduit noemt. Twee IKE-implementaties kunnen niet beide antwoorden op hetzelfde lokale adres en dezelfde UDP-poort, en geen enkele hoeveelheid opnieuw proberen verandert dat.

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'

Welke regel ook bij uw platform past, het antwoord dat u wilt is een proces en de dienst die het heeft voortgebracht. Als de luisteraar de ingebouwde IKE-dienst is, is de tweede client de indringer; als het een leveranciersagent is, is de ingebouwde client dat. Bepaal welke bij aanmelding mag starten en schakel de autostart van de andere uit in plaats van hem elke sessie te doden.

Het filterstuurprogramma zit onder uw routes

Een netwerkfilterstuurprogramma onderschept verkeer tussen de adapter en de protocolstack, dus het kan pakketten herschrijven of blokkeren ongeacht wat de routetabel zegt. Zo wordt een route die er correct uitziet genegeerd, en daarom kan een geslaagde ping naast een browser staan die niets kan laden.

Leverancierscomponenten binden zich ook aan specifieke verbindingen. Een oud filter dat aan één adapter is gebonden kan een verder correct profiel verhinderen zijn handdruk te voltooien, en dat onderdeel loskoppelen van de adaptereigenschappen is smaller en omkeerbaarder dan het product volledig verwijderen. Omdat de binding per verbinding is, vergelijk de adapters in plaats van de hele stack.

Bepaal welk product de opstart bezit, en leg het vast

Samenleven is alleen realistisch wanneer de twee clients naar ontwerp verschillende lagen bezetten, zoals een IPsec-stack naast een proxy die alleen applicatieverkeer afhandelt. Waar beide dezelfde poort, dezelfde filterlaag of het recht willen om een standaardroute te publiceren, blijven ze elkaar afwisselen en elke storing zal als een nieuwe fout lijken.

Kies de eigenaar bewust. Vormen die een herstart overleven zijn onder meer de tweede client in een virtuele machine draaien, hem op speciale hardware houden, of standaardiseren op één client die beide protocollen spreekt. De autostart en dienst van de verliezer uitschakelen is een kleinere wijziging dan de routetabel na elke start opnieuw opbouwen, en het wordt met één instellingswijziging teruggedraaid.