Brekt in dielde pppd-opsjesbestân jo oare VPN?
Twa PPP-basearre VPN-klanten kinne deselde pppd-standertwearden lêze, dus in repaasje foar de iene feroaret stil de oare. Spoarje earst de eigner fan de opsje op foardat jo bewurkje.
Jo foegje ien rigel ta om in koppich PPTP-profyl ferbine te litten, en in wike letter stopet de L2TP-klant dy't moannen wurke hie. De foar de hân lizzende lêzing is dat de twa protokollen no konflikt hawwe. Fakener starte beide klanten pppd, beide lêze deselde standertwearden, en de rigel dy't jo tafoege wie nea beheind ta it profyl dat jo oan it reparearjen wiene. It dielde opsjesbestân is de keppeling, en de protokollen binne ûnskuldich.
Wat in klant erft as it begjint
In PPP-basearre klant bout selden syn kommandorigel fan neat. It startet pppd, dat systeemstandertwearden lêst, dan elk brûker- of terminalbestân, dan de arguminten dy't de klant trochjout, en de klant kin it ek nei in peer-bestân wize. Elk fan dy lagen kin in plugin, in autentikaasjemetoade of in rûtedirektive drage, en de earste laach dy't in beskerme opsje set, kin it tsjin lettere feroarings ôfslute.
De nuttige fraach is dus net hokker VPN stikken is, mar hokker laach de ynstelling joech. In klant dy't syn eigen arguminten generearret liket selsstannich en erft dochs alles wat it systeembestân befettet.
Bepaal de oarsprong fan de rigel foardat jo him feroarje
Begjin mei te sjen nei it proses dat rint wylst in ferbining aktyf is. De kommandorigel lit sjen hokker bestannen eksplisyt trochjûn binne, en alles wat dêr net neamd wurdt, komt fan in standertpaad.
ps -o pid=,args= -C pppdAs de argumintlist in peer-namme befettet, lês dat bestân. Sa net, dan wennet de ynstelling dy't jo efterfolgje op in dield paad. De pppd-hânlieding listet de folchoarder op wêryn dy bestannen lêzen wurde en hokker opsjes in gewoane brûker net oerskriuwe kin, en dêrom docht in lettere rigel soms hielendal neat. In beskerme opsje lykas in pluginpaad kin net ferfongen wurde troch in lettere rigel op brûkersnivo, dus it bewurkjen fan it ferkearde bestân hat gjin sichtber effekt.
De plugin-rigel dy't elke klant folget
In plugin laden yn it systeembestân is de slimste oertreder, want it feroaret wat in nij PPP-proses besiket te laden, nettsjinsteande hokker knop de brûker yndrukt hat. De L2TP-plugin is it klassike foarbyld: korrekt foar ien profyl, betsjuttingsleas of skealik foar in PPTP-profyl dat fan deselde standertwearden begjint.
Ferpleats it nei in peer-bestân dat de klant kiest, of nei de eigen ynstellingen fan de klant per ferbining as dy se stipet. It samar fuortsmite reparearret de twadde klant en brekt de earste, en sa reizgje dizze problemen tusken teams.
Kontrolearje elke klant nei de ferpleatsing
Test beide ferbiningen fan deselde masine, efter elkoar, en lês de ûnderhannele opsjes ynstee fan de súksesdialooch. De dump hjirûnder prints it opsjeset dat pppd eins gearstalde, en dat is de iennichste list dy't ta docht.
sudo pppd call office debug dumpWerhelje foar de twadde klant en fergelykje de twa útgongen. De opsje dy't jo ferpleatst hawwe, moat yn presys ien fan beide ferskine. As it yn beide ferskynt, generearret de klant it op 'e nij en heart de repaasje by dat profyl ynstee fan by it dielde bestân. Skriuw op wêr't de ynstelling no wennet njonken de ferbining, sadat de folgjende persoan de keppeling net wer ûntdekt troch him op 'e nij te brekken.