Tilkoplinga autentiserer, klienten rapporterer tilkopla, og eitt sekund seinare lukkar loggen med LCP avslutta av peer. Den linja kjem frå PPP-forhandlinga inne i GRE-tunnelen, så transporten verka allereie, og dei to endane var usamde om vala for tilkoplinga. Passord og serveradresser er vanlegvis uskuldige her. Krypteringspolicyen er det første som må samanliknast, og på Linux er pppd-peerfila det første staden å sjå.

Kva LCP-feilen seier om PPP-trinnet

PPTP pakkar PPP inn i GRE: TCP 1723-kontrolltilkoplinga set opp anropet, GRE ber nyttelasta, og deretter forhandlar LCP om val som autentiseringsprotokoll, komprimering og MPPE. Peeren avsluttar LCP når eit påkravd val ikkje er akseptabelt på hans side. Ein logg der CHAP- eller MSCHAPv2-utvekslinga blir fullført og LCP sluttar rett etterpå, er ei policyavvising, ikkje ein feil i nåbarheita. Om tunnelen aldri når forhandlinga, undersøk pppd og plugin-modulen før du les LCP-linja.

To føresetnader er lette å oversjå. pppd-binæra må finnast, og PPTP-plugin-modulen som er nemnd i peerfila, må vere installert; ein manglande pakke avsluttar anropet før noko val blir drøfta.

Aktiver MPPE på sida som krev det

Den eigentlege avgjerda er kva ende som eig krypteringspolicyen. Ein klient kan tilby MPPE, krevje det eller avslå det, og serveren gjer same valet. Når begge krev det, kjem tilkoplinga opp; når éin krev og den andre avslår, sluttar LCP.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

Last modulen med modprobe ppp_mppe før du ringjer, fordi require-mppe-128 feilar utan han. På Windows er den tilsvarande kontrollen sikkerheitsfana i VPN-oppføringa, der klienten må få beskjed om å krevje kryptering i staden for å godta det serveren tilbyr. Om serveren framleis avsluttar LCP, spør operatøren om MPPE er obligatorisk, valfritt eller deaktivert, sidan ein klient ikkje kan forhandle om vern som serveren avviser. Å slå av kryptering for at meldinga skal forsvinne er feil veg: det fjernar det einaste vernet denne protokollen har.

Lagre den fungerande peerfila før du redigerer ho. Ei feilskriven require-mppe-linje attskapar den same generiske LCP-feilen og sender deg tilbake til start.

Les loggen til pppd sjølv i staden for appletten

Skrivebordsapplettar viser fråkoblinga og skjuler årsaka, så les framstillinga til demonen av eitt forsøk. På systemd-system endar meldinga i journalen; eldre oppsett skriv til dei tradisjonelle loggfilene.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

Søk i eit vindauge rundt eitt enkelt anrop i staden for ein heil dag med gjenoppkoplingar, slik at det avviste valet er lett å sjå. pppd nemner vanlegvis valet og svaret til peeren, noko som fortel deg om du skal endre ditt eige framlegg eller be serversida lempe på kravet. Hald forsøka tidsstempla, fordi samanlikning av to loggar berre er nyttig når du veit kva linjer som høyrer til kva anrop. Når inga LCP-utveksling blir vist i det heile, ligg feilen tidlegare i kjeda, og MPPE er ikkje den mistenkte.

Hald rettinga gjennom gjenoppkoplingar: hook-namn og MTU

Når tilkoplinga først held seg oppe, avgjer to detaljar om ho overlever ei gjenoppkopling. Hookar ligg i /etc/ppp/ip-up.d og /etc/network/if-up.d, og begge katalogane blir handsama av run-parts, der filnamnsfilteret avviser alt som inneheld eit punktum. Eit skript kalla set-pptp.sh blir derfor hoppa over, medan set-pptp blir køyrt. Sjekk namnet før du feilsøkjer innhaldet i skriptet, og set deretter den mindre MTU-en frå innsida av den hooken, slik at kvart nytt ppp-grensesnitt arvar han utan ein manuell kommando.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

For å avslutte ei økt med vilje, målrett pid-en som pppd har registrert, i staden for å mønstermatche prosessnamn, fordi drap på alt som inneheld ppp også riv ned urelaterte lenkjer. PPTP er utdatert, og MS-CHAPv2 er svakt, så handsam desse sjekkane som vedlikehald av ei lenkje som må halde fram med å verke, ikkje som grunn til å rulle ut PPTP nokon ny stad.

Relaterte artiklar