Breekt een gedeeld pppd-optiesbestand je andere VPN?

Je voegt één regel toe om een koppig PPTP-profiel te laten verbinden, en een week later stopt de L2TP-client die maandenlang werkte. De voor de hand liggende lezing is dat de twee protocollen nu botsen. Vaker starten beide clients pppd, lezen beide dezelfde standaardwaarden, en was de regel die je toevoegde nooit beperkt tot het profiel dat je aan het repareren was. Het gedeelde optiebestand is de koppeling, en de protocollen zijn onschuldig.

Wat een client erft wanneer hij start

Een op PPP gebaseerde client bouwt zijn commandoregel zelden vanaf niets op. Hij start pppd, dat de systeemstandaarden leest, dan een gebruikers- of terminalbestand, dan de argumenten die de client doorgeeft, en de client kan hem ook naar een peer-bestand wijzen. Elk van die lagen kan een plugin, een authenticatiemethode of een routedirectief bevatten, en de eerste laag die een beschermde optie zet, kan die optie tegen latere wijzigingen vergrendelen.

De nuttige vraag is dus niet welke VPN kapot is, maar welke laag de instelling leverde. Een client die zijn eigen argumenten genereert lijkt op zichzelf staand en erft toch alles wat het systeembestand bevat.

Herleid de regel voordat je hem wijzigt

Begin met het proces dat draait terwijl een verbinding actief is. De commandoregel toont welke bestanden expliciet zijn doorgegeven, en alles wat daar niet genoemd wordt kwam uit een standaardpad.

ps -o pid=,args= -C pppd

Staat er een peernaam in de argumentenlijst, lees dat bestand dan. Is dat niet zo, dan woont de instelling die je zoekt in een gedeeld pad. De pppd-handleiding noemt de volgorde waarin die bestanden worden gelezen en welke opties een gewone gebruiker niet kan overschrijven; daarom doet een latere regel soms helemaal niets. Een beschermde optie zoals een pluginpad kan niet door een latere regel op gebruikersniveau worden vervangen, dus het verkeerde bestand aanpassen heeft geen zichtbaar effect.

De pluginregel die elke client volgt

Een plugin die in het systeembestand wordt geladen is de ergste boosdoener, want hij verandert wat een nieuw PPP-proces probeert te laden, ongeacht op welke knop de gebruiker heeft gedrukt. De L2TP-plugin is het klassieke voorbeeld: correct voor het ene profiel, betekenisloos of schadelijk voor een PPTP-profiel dat van dezelfde standaardwaarden vertrekt.

Verplaats hem naar een peer-bestand dat de client kiest, of naar de eigen instellingen per verbinding als de client die ondersteunt. Hem gewoon verwijderen repareert de tweede client en breekt de eerste, en zo reizen dit soort problemen tussen teams.

Controleer elke client na het verplaatsen

Test beide verbindingen vanaf dezelfde machine, de een na de ander, en lees de onderhandelde opties in plaats van het succesvenster. De dump hieronder print de optieset die pppd werkelijk heeft samengesteld, en alleen die lijst telt.

sudo pppd call office debug dump

Herhaal dit voor de tweede client en vergelijk de twee uitvoer. De optie die je hebt verplaatst hoort in precies één ervan te staan. Staat hij in beide, dan genereert de client hem opnieuw en hoort de oplossing in dat profiel, niet in het gedeelde bestand. Noteer naast de verbinding waar de instelling nu woont, zodat de volgende persoon de koppeling niet opnieuw ontdekt door hem weer te breken.