Krossar en delad pppd-inställningsfil din andra VPN?

Du lägger till en rad för att ett envis PPTP-profil ska ansluta, och en vecka senare slutar L2TP-klienten som fungerat i månader att fungera. Den självklara tolkningen är att de två protokollen nu krockar. Oftare startar båda klienterna pppd, båda läser samma standardvärden, och raden du lade till var aldrig begränsad till profilen du försökte laga. Den delade inställningsfilen är kopplingen, och protokollen är oskyldiga.

Vad en klient ärver när den startar

En PPP-baserad klient bygger sällan sin kommandorad från noll. Den startar pppd, som läser systemets standardvärden, sedan en användar- eller terminalfil, sedan de argument klienten skickar, och klienten kan även peka den mot en peer-fil. Vart och ett av dessa lager kan bära en plugin, en autentiseringsmetod eller ett rutt-direktiv, och det första lagret som sätter ett skyddat alternativ kan låsa det mot senare ändringar.

Den användbara frågan är alltså inte vilken VPN som är trasig utan vilket lager som levererade inställningen. En klient som genererar sina egna argument ser självständig ut men ärver ändå allt som systemfilen innehåller.

Spåra raden innan du ändrar den

Börja med att titta på processen som körs medan en anslutning är uppe. Kommandoraden visar vilka filer som skickades explicit, och allt som inte nämns där kom från en standardväg.

ps -o pid=,args= -C pppd

Om argumentlistan innehåller ett peer-namn, läs den filen. Om inte, bor inställningen du jagar i en delad sökväg. pppd-handboken listar i vilken ordning filerna läses och vilka alternativ en vanlig användare inte kan åsidosätta, vilket är varför en senare rad ibland inte gör någonting alls. Ett skyddat alternativ som en pluginväg kan inte ersättas av en senare rad på användarnivå, så att redigera fel fil ger ingen synlig effekt.

Pluginraden som följer varje klient

En plugin som laddas i systemfilen är den värsta boven eftersom den ändrar vad en ny PPP-process försöker ladda, oavsett vilken knapp användaren tryckte på. L2TP-pluginen är det klassiska exemplet: rätt för en profil, meningslös eller skadlig för en PPTP-profil som utgår från samma standardvärden.

Flytta den till en peer-fil som klienten väljer, eller till klientens egna inställningar per anslutning om den stöder det. Att bara radera den reparerar den andra klienten och förstör den första, och det är så de här problemen vandrar mellan team.

Verifiera varje klient efter flytten

Testa båda anslutningarna från samma maskin, en efter en, och läs de förhandlade alternativen i stället för framgångsdialogen. Dumpen nedan skriver ut den uppsättning alternativ som pppd faktiskt satte ihop, och det är den enda listan som spelar roll.

sudo pppd call office debug dump

Upprepa för den andra klienten och jämför de två utskrifterna. Alternativet du flyttade ska visas i exakt en av dem. Visas det i båda genererar klienten det igen och rättelsen hör hemma i den profilen, inte i den delade filen. Anteckna var inställningen nu bor bredvid anslutningen, så att nästa person inte upptäcker kopplingen igen genom att bryta den på nytt.