Ødelægger en delt pppd-indstillingsfil din anden VPN?

Du tilføjer én linje for at få en genstridig PPTP-profil til at forbinde, og en uge senere stopper L2TP-klienten, der havde virket i månedsvis. Den oplagte læsning er, at de to protokoller nu er i konflikt. Oftere starter begge klienter pppd, begge læser de samme standarder, og linjen, du tilføjede, var aldrig begrænset til den profil, du reparerede. Den delte indstillingsfil er koblingen, og protokollerne er uskyldige.

Hvad en klient arver, når den starter

En PPP-baseret klient bygger sjældent sin kommandolinje fra ingenting. Den starter pppd, som læser systemstandarder, derefter enhver bruger- eller terminalfil, derefter de argumenter, klienten sender, og klienten kan også pege den mod en peer-fil. Hvert af disse lag kan bære et plugin, en godkendelsesmetode eller en rutedirektiv, og det første lag, der sætter en beskyttet indstilling, kan låse den mod senere ændringer.

Så det nyttige spørgsmål er ikke, hvilken VPN der er ødelagt, men hvilket lag der leverede indstillingen. En klient, der genererer sine egne argumenter, ser selvforsynende ud og arver stadig alt, hvad systemfilen indeholder.

Fastslå linjens oprindelse, før du ændrer den

Begynd med at se på den proces, der kører, mens en forbindelse er oppe. Kommandolinjen viser, hvilke filer der blev sendt eksplicit, og alt, der ikke er nævnt der, kom fra en standardsti.

ps -o pid=,args= -C pppd

Hvis argumentlisten indeholder et peer-navn, læs den fil. Hvis ikke, bor den indstilling, du jagter, på en delt sti. Den pppd-manualen viser rækkefølgen, hvori disse filer læses, og hvilke indstillinger en almindelig bruger ikke kan tilsidesætte, og derfor gør en senere linje nogle gange slet ingenting. En beskyttet indstilling som en pluginsti kan ikke erstattes af en senere linje på brugerniveau, så redigering af den forkerte fil har ingen synlig effekt.

Plugin-linjen, der følger hver klient

Et plugin indlæst i systemfilen er den værste synder, fordi det ændrer, hvad en ny PPP-proces forsøger at indlæse, uanset hvilken knap brugeren trykkede på. L2TP-pluginet er det klassiske eksempel: korrekt for én profil, meningsløst eller skadeligt for en PPTP-profil, der starter fra de samme standarder.

Flyt det til en peer-fil, som klienten vælger, eller til klientens egne indstillinger pr. forbindelse, når den understøtter dem. Sletning med det samme reparerer den anden klient og ødelægger den første, og det er sådan, disse problemer rejser mellem teams.

Kontroller hver klient efter flytningen

Test begge forbindelser fra samme maskine, én efter den anden, og læs de forhandlede indstillinger i stedet for succesdialogen. Dumpet nedenfor udskriver det sæt indstillinger, som pppd faktisk samlede, og det er den eneste liste, der betyder noget.

sudo pppd call office debug dump

Gentag for den anden klient, og sammenlign de to uddata. Den indstilling, du flyttede, bør optræde i præcis én af dem. Hvis den optræder i begge, genskaber klienten den, og rettelsen hører til den profil frem for den delte fil. Notér, hvor indstillingen nu bor ved siden af forbindelsen, så den næste person ikke genopdager koblingen ved at ødelægge den igen.