PPTP-klienter på DD-WRT kan ikke nå hinanden: fem kontroller

To laptops dialer ind på PPTP-serveren på en DD-WRT-boks, hver får en adresse, og ingen af dem kan pinge den anden. Delte mapper dukker aldrig op, og den første tanke er, at den 255.255.255.255-maske routeren uddeler, må være forkert. Det er ikke årsagen, og en ændring skaber ikke en enkelt ny nabo. Gå de fem kontroller nedenfor igennem i rækkefølge, og stop så snart en af dem fejler, for hver har sin egen kur.

Kontrol et: /32 er ikke fejlen

PPTP bærer PPP, og en PPP-forbindelse forbinder præcis to endepunkter: din klient og serveren. En netmaske beskriver, hvilke adresser der deler et lokalt segment, og her er der intet segment, kun peeren i den anden ende af én ledning. En maske med kun ettaller siger præcis det, så DD-WRT uddeler den korrekte værdi for denne forbindelsestype. Adressen er en peer-adresse, ikke en interface-adresse på et LAN.

En maske på 255.255.255.0 hører til på et delt medie med hundredvis af enheder, og at sætte den på et PPP-interface gør heller ikke den anden side af tunnelen til en nabo.

Kontrol to: læs værdierne på PPTP-server-siden

Alle de vigtige indstillinger står under Tjenester, VPN, PPTP-server. Aktivér serveren, sæt serveradressen til routerens LAN-adresse, og hold klientområdet uden for DHCP-poolen, så en indringende klient og en kablet maskine ikke får samme adresse. Tilføj under CHAP-Secrets én linje pr. konto i formen username * password *, uden mellemrum i navnet. Anvend, og forbind derefter med en profil, der navngiver routeren og en af de konti.

Hvor klienten stopper, fortæller dig, hvilket lag du skal undersøge. En klient, der godkendes, men ikke får en adresse, er et pool- eller secrets-problem; en klient, der får en adresse og ikke når noget, er et routing- eller firewall-problem.

Kontrol tre: se efter en rute mellem de to peers

Hver tunnel, der afsluttes på routeren, er sit eget interface, som regel ppp0, ppp1 og så videre. Trafik fra den ene klient til den anden skal routes mellem de interfaces, og routeren skal være villig til at videresende den. Kør ip route på routeren og se efter en host-rute for hver tilsluttet peer, der peger på det matchende PPP-interface. Mangler en peer en rute, er tunnelen ikke helt oppe, uanset hvad klientens statusskærm påstår.

To host-ruter til to separate ppp-interfaces er den form, du vil have, før du går videre.

Kontrol fire: undersøg FORWARD-kæden, ikke INPUT

Trafik mellem klienter videresendes, accepteres ikke lokalt, så INPUT-kæden er det forkerte sted at kigge. Kør iptables -L FORWARD -v -n og se efter en drop-regel, der fanger PPP-interfaces, plus pakketællerne, der viser, om der overhovedet ankommer noget til kæden. En standard drop-politik uden accept-regel for tunneltrafik giver præcis det symptom, du startede med: hver klient alene er fin, sammen er de usynlige for hinanden.

Hvis små pings virker, og store overførsler går i stå, bliver tunnelen fragmenteret i stedet for blokeret. PPTP over PPP vil normalt have en MTU og MRU omkring 1450, og lades de på 1500, får du en forbindelse, der klarer håndtryk og fejler på rigtig last.

Kontrol fem: beslut, hvad internetadgang skal gøre

Klienter, der skal browse gennem kontoret, har brug for kildetranslation mod WAN-interfacet. Klienter, der kun skal nå LAN'et, har brug for en rute og intet andet. Det er forskellige hensigter med forskellige regelsæt, og maske-spørgsmålet skjuler denne anden beslutning fuldstændigt. Skriv ned, hvilken adfærd du ønskede, før du tilføjer en enkelt regel, for en klient, der uventet går ud gennem kontorlinjen, er en overraskelse, der dukker op på et møde frem for i en log.

En sidste note, uden relation til rettelsen: PPTP er forældet, og dets godkendelse har været brudt i årevis. Tjeklisten ovenfor forklarer stadig, hvad en PPP-forbindelse gør, og samme ræsonnement gælder, hvis du senere flytter klienterne til en moderne tunnel.