Breek 'n gedeelde pppd-opsielêer jou ander VPN?

Jy voeg een reël by om 'n koppige PPTP-profiel te laat verbind, en 'n week later hou die L2TP-kliënt wat maande lank gewerk het op. Die ooglopende verklaring is dat die twee protokolle nou bots. Meer dikwels begin beide kliënte pppd, albei lees dieselfde verstekkeuses, en die reël wat jy bygevoeg het was nooit tot die profiel wat jy regmaak beperk nie. Die gedeelde opsielêer is die koppeling, en die protokolle is onskuldig.

Wat 'n kliënt erf wanneer dit begin

'n PPP-gebaseerde kliënt bou selde sy opdragreël uit niks. Dit begin pppd, wat stelselverstekke lees, dan enige gebruiker- of terminaallêer, dan die argumente wat die kliënt deurgee, en die kliënt kan dit ook na 'n portuur-lêer wys. Elkeen van daardie lae kan 'n inprop, 'n verifikasiemetode of 'n roete-opdrag dra, en die eerste laag wat 'n beskermde opsie stel, kan dit teen latere veranderinge sluit.

Die nuttige vraag is dus nie watter VPN stukkend is nie, maar watter laag die instelling verskaf het. 'n Kliënt wat sy eie argumente genereer lyk selfstandig en erf steeds alles wat die stelsellêer bevat.

Wys die reël toe voordat jy dit verander

Begin deur na die proses te kyk wat loop terwyl 'n verbinding aktief is. Die opdragreël wys watter lêers uitdruklik deurgegee is, en enigiets wat nie daar genoem word nie, kom uit 'n verstekpad.

ps -o pid=,args= -C pppd

As die argumentlys 'n portuur se naam bevat, lees daardie lêer. Indien nie, woon die instelling wat jy najaag in 'n gedeelde pad. Die pppd-handleiding lys die volgorde waarin daardie lêers gelees word en watter opsies 'n gewone gebruiker nie kan oorheers nie, en daarom doen 'n latere reël soms heeltemal niks. 'n Beskermde opsie soos 'n inprop-pad kan nie deur 'n latere gebruikersvlak-reël vervang word nie, so om die verkeerde lêer te wysig het geen sigbare uitwerking nie.

Die inprop-reël wat elke kliënt volg

'n Inprop wat in die stelsellêer gelaai word, is die ergste oortreder, want dit verander wat 'n nuwe PPP-proses probeer laai, maak nie saak watter knoppie die gebruiker gedruk het nie. Die L2TP-inprop is die klassieke voorbeeld: korrek vir een profiel, betekenisloos of skadelik vir 'n PPTP-profiel wat van dieselfde verstekkeuses begin.

Skuif dit na 'n portuur-lêer wat die kliënt kies, of na die kliënt se eie instellings per verbinding wanneer dit dit ondersteun. Om dit heeltemal te verwyder maak die tweede kliënt reg en breek die eerste, en dit is hoe hierdie probleme tussen spanne rondbeweeg.

Verifieer elke kliënt ná die skuif

Toets albei verbindings vanaf dieselfde masjien, een na die ander, en lees die onderhandelde opsies eerder as die suksesdialoog. Die uitskrif hieronder druk die opsiestel wat pppd werklik saamgestel het, en dit is die enigste lys wat saak maak.

sudo pppd call office debug dump

Herhaal dit vir die tweede kliënt en vergelyk die twee uitvoere. Die opsie wat jy geskuif het, moet in presies een van hulle verskyn. As dit in albei verskyn, genereer die kliënt dit weer, en die regstelling hoort in daardie profiel eerder as in die gedeelde lêer. Teken aan waar die instelling nou woon, langs die verbinding, sodat die volgende persoon nie die koppeling weer ontdek deur dit te breek nie.