PPTP-klientar på DD-WRT når ikkje kvarandre: fem kontrollar

To laptoppar ringjer inn til PPTP-tenaren på ein DD-WRT-boks, kvar får ei adresse, og ingen av dei kan pinga den andre. Delte mapper dukkar aldri opp, og den første tanken er at maska 255.255.255.255 som rutaren deler ut, må vere feil. Ho er ikkje årsaka, og å endra henne skaper ikkje éin ny nabo. Gå gjennom dei fem kontrollane nedanfor i rekkjefølgje og stopp så snart ein feilar, for kvar har si eiga kur.

Kontroll éin: /32 er ikkje feilen

PPTP ber PPP, og ei PPP-lenke knyter saman nøyaktig to endepunkt: klienten din og tenaren. Ei netmaske skildrar kva adresser som deler eit lokalt segment, og her finst det ikkje noko segment, berre peer-en i den andre enden av éin leidning. Ei maske med berre einarar seier nettopp dette, så DD-WRT deler ut den rette verdien for denne lenketypen. Adressa er ei peer-adresse, ikkje ei grensesnittadresse på eit LAN.

Ei maske på 255.255.255.0 høyrer heime på eit delt medium med hundrevis av einingar, og å setja henne på eit PPP-grensesnitt gjer heller ikkje den andre sida av tunnelen til ein nabo.

Kontroll to: les verdiane på PPTP-tenarsida

Alle innstillingane som betyr noko, ligg under Tenester, VPN, PPTP-tenar. Slå på tenaren, set tenaradressa til LAN-adressa til rutaren, og hald klientområdet utanfor DHCP-poolen slik at ein innringande klient og ein kabelbunden maskin ikkje får same adresse. Under CHAP-Secrets legg du til éi line per konto i forma username * password *, utan mellomrom i namnet. Bruk, og kople deretter til med ein profil som namngjev rutaren og ein av desse kontoane.

Kvar klienten stoppar, fortel deg kva lag du skal undersøkja. Ein klient som autentiserer men ikkje får adresse, er eit pool- eller løyndomsproblem; ein klient som får adresse og ikkje når noko, er eit rutings- eller brannmurproblem.

Kontroll tre: sjå etter ei rute mellom dei to peer-ane

Kvar tunnel som endar på rutaren, er sitt eige grensesnitt, vanlegvis ppp0, ppp1 og så bortetter. Trafikk frå éin klient til den andre må rutast mellom desse grensesnitta, og rutaren må vere viljug til å senda han vidare. Køyr ip route på rutaren og sjå etter ei vertsrute for kvar tilkopla peer, som peikar på det tilsvarande PPP-grensesnittet. Manglar ein peer ei rute, er ikkje tunnelen heilt oppe, kva klienten sin statusskjerm enn påstår.

To vertsruter til to separate ppp-grensesnitt er forma du vil ha før du går vidare.

Kontroll fire: sjå på FORWARD-kjeda, ikkje INPUT

Trafikk mellom klientar blir sendt vidare, ikkje teken imot lokalt, så INPUT-kjeda er feil stad. Køyr iptables -L FORWARD -v -n og sjå etter ein drop-regel som fangar PPP-grensesnitta, i tillegg til pakketeljarane som viser om noko i det heile kjem til kjeda. Ein standard drop-policy utan accept-regel for tunneltrafikk gjev nøyaktig det symptomet du starta med: kvar klient åleine er i orden, saman er dei usynlege for kvarandre.

Viss små ping fungerer og store overføringar stoppar, blir tunnelen fragmentert i staden for blokkert. PPTP over PPP vil normalt ha ein MTU og MRU rundt 1450, og lèt du dei stå på 1500, får du ei lenke som klarar handtrykk og feilar på røynd last.

Kontroll fem: avgjer kva internettilgangen skal gjere

Klientar som skal surfa gjennom kontoret, treng kjeldeomsetjing mot WAN-grensesnittet. Klientar som berre skal nå LAN-et, treng ei rute og ingenting anna. Dette er ulike føremål med ulike regelsett, og maskespørsmålet gøymer denne andre avgjerda heilt. Skriv ned kva åtferd du ønskte før du legg til ein einaste regel, for ein klient som uventa går ut gjennom kontorlinja, er ei overrasking som dukkar opp i eit møte og ikkje i ein logg.

Ei siste merknad, utan samanheng med rettinga: PPTP er utdatert, og autentiseringa har vore broten i årevis. Lista ovanfor forklarar framleis kva ei PPP-lenke gjer, og same resonnementet gjeld viss du seinare flyttar klientane til ein moderne tunnel.