PPTP-klienter på DD-WRT når ikke hverandre: fem kontroller

To laptoper ringer inn til PPTP-serveren på en DD-WRT-boks, hver får en adresse, og ingen av dem kan pinge den andre. Delte mapper dukker aldri opp, og den første tanken er at masken 255.255.255.255 som ruteren deler ut, må være feil. Den er ikke årsaken, og å endre den skaper ikke én ny nabo. Gå gjennom de fem kontrollene nedenfor i rekkefølge og stopp så snart en feiler, for hver har sin egen kur.

Kontroll én: /32 er ikke feilen

PPTP bærer PPP, og en PPP-lenke forbinder nøyaktig to endepunkter: klienten din og serveren. En nettmaske beskriver hvilke adresser som deler et lokalt segment, og her finnes det ikke noe segment, bare peer-en i den andre enden av én ledning. En maske med bare enere sier nettopp dette, så DD-WRT deler ut den riktige verdien for denne lenketypen. Adressen er en peer-adresse, ikke en grensesnittadresse på et LAN.

En maske på 255.255.255.0 hører hjemme på et delt medium med hundrevis av enheter, og å sette den på et PPP-grensesnitt gjør heller ikke den andre siden av tunnelen til en nabo.

Kontroll to: les verdiene på PPTP-server-siden

Alle innstillingene som betyr noe, ligger under Tjenester, VPN, PPTP-server. Slå på serveren, sett serveradressen til ruterens LAN-adresse, og hold klientområdet utenfor DHCP-poolen slik at en innringende klient og en kablet maskin ikke får samme adresse. Under CHAP-Secrets legger du til én linje per konto i formen username * password *, uten mellomrom i navnet. Bruk, og koble deretter til med en profil som navngir ruteren og en av disse kontoene.

Hvor klienten stopper, forteller deg hvilket lag du skal undersøke. En klient som autentiseres men ikke får adresse, er et pool- eller hemmelighetsproblem; en klient som får adresse og ikke når noe, er et ruting- eller brannmurproblem.

Kontroll tre: se etter en rute mellom de to peer-ene

Hver tunnel som avsluttes på ruteren, er sitt eget grensesnitt, vanligvis ppp0, ppp1 og så videre. Trafikk fra én klient til den andre må rutes mellom disse grensesnittene, og ruteren må være villig til å videresende den. Kjør ip route på ruteren og se etter en vertsrute for hver tilkoblet peer, som peker på det tilsvarende PPP-grensesnittet. Mangler en peer en rute, er ikke tunnelen helt oppe, uansett hva klientens statusskjerm påstår.

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

Kontroll fire: se på FORWARD-kjeden, ikke INPUT

Trafikk mellom klienter videresendes, ikke godtas lokalt, så INPUT-kjeden er feil sted. Kjør iptables -L FORWARD -v -n og se etter en drop-regel som fanger PPP-grensesnittene, i tillegg til pakketellerne som viser om noe i det hele tatt kommer til kjeden. En standard drop-policy uten accept-regel for tunneltrafikk gir nøyaktig det symptomet du startet med: hver klient alene er i orden, sammen er de usynlige for hverandre.

Hvis små pinger virker og store overføringer stopper, blir tunnelen fragmentert i stedet for blokkert. PPTP over PPP vil normalt ha en MTU og MRU rundt 1450, og lar du dem stå på 1500, får du en lenke som klarer håndtrykk og feiler på reell last.

Kontroll fem: bestem hva internettilgangen skal gjøre

Klienter som skal surfe gjennom kontoret, trenger kildeoversettelse mot WAN-grensesnittet. Klienter som bare skal nå LAN-et, trenger en rute og ingenting annet. Dette er ulike hensikter med ulike regelsett, og maskespørsmålet skjuler denne andre beslutningen fullstendig. Skriv ned hvilken oppførsel du ønsket før du legger til en eneste regel, for en klient som uventet går ut gjennom kontorlinjen, er en overraskelse som dukker opp i et møte og ikke i en logg.

En siste merknad, uten forbindelse til rettelsen: PPTP er utdatert, og autentiseringen har vært brutt i årevis. Listen ovenfor forklarer fortsatt hva en PPP-lenke gjør, og samme resonnement gjelder hvis du senere flytter klientene til en moderne tunnel.