PPTP-klienter på DD-WRT når inte varandra: fem kontroller

Två bärbara datorer ringer in till PPTP-servern på en DD-WRT-box, var och en får en adress, och ingen av dem kan pinga den andra. Delade mappar dyker aldrig upp och den första tanken är att masken 255.255.255.255 som routern delar ut måste vara fel. Den är inte orsaken, och att ändra den skapar inte en enda ny granne. Gå igenom de fem kontrollerna nedan i ordning och stanna så snart en fallerar, för var och en har sitt eget botemedel.

Kontroll ett: /32 är inte felet

PPTP bär PPP, och en PPP-länk förbinder exakt två ändpunkter: din klient och servern. En nätmask beskriver vilka adresser som delar ett lokalt segment, och här finns inget segment, bara peeren i andra ändan av en enda ledning. En mask med bara ettor säger precis det, så DD-WRT delar ut rätt värde för den här länktypen. Adressen är en peer-adress, inte en gränssnittsadress på ett LAN.

En mask på 255.255.255.0 hör hemma på ett delat medium med hundratals enheter, och att sätta den på ett PPP-gränssnitt gör inte heller andra sidan av tunneln till en granne.

Kontroll två: läs värdena på PPTP-serversidan

Alla inställningar som spelar roll finns under Tjänster, VPN, PPTP-server. Aktivera servern, sätt serveradressen till routerns LAN-adress och håll klientintervallet utanför DHCP-poolen så att en inringande klient och en kabelansluten maskin inte får samma adress. Under CHAP-Secrets lägger du till en rad per konto i formen username * password *, utan blanksteg i namnet. Verkställ och anslut sedan med en profil som namnger routern och ett av dessa konton.

Var klienten stannar talar om vilket lager du ska undersöka. En klient som autentiserar men inte får någon adress är ett pool- eller hemlighetsproblem; en klient som får en adress och inte når något är ett routing- eller brandväggsproblem.

Kontroll tre: leta efter en rutt mellan de två peerarna

Varje tunnel som slutar på routern är sitt eget gränssnitt, vanligtvis ppp0, ppp1 och så vidare. Trafik från en klient till den andra måste routas mellan dessa gränssnitt, och routern måste vara villig att vidarebefordra den. Kör ip route på routern och leta efter en värdrutt för varje ansluten peer som pekar på motsvarande PPP-gränssnitt. Saknar en peer en rutt är tunneln inte helt uppe, vad klientens statusskärm än påstår.

Två värdrutter till två separata ppp-gränssnitt är den form du vill ha innan du går vidare.

Kontroll fyra: titta på FORWARD-kedjan, inte INPUT

Trafik mellan klienter vidarebefordras, accepteras inte lokalt, så INPUT-kedjan är fel plats. Kör iptables -L FORWARD -v -n och leta efter en drop-regel som fångar PPP-gränssnitten, plus paketräknarna som visar om något alls når kedjan. En standard-drop-policy utan accept-regel för tunneltrafik ger exakt det symptom du började med: varje klient för sig är okej, tillsammans är de osynliga för varandra.

Om små ping fungerar och stora överföringar fastnar fragmenteras tunneln i stället för att blockeras. PPTP över PPP vill normalt ha MTU och MRU runt 1450, och lämnas de på 1500 får du en länk som klarar handskakningar och fallerar på verklig last.

Kontroll fem: bestäm vad internetåtkomsten ska göra

Klienter som ska surfa genom kontoret behöver källöversättning mot WAN-gränssnittet. Klienter som bara ska nå LAN behöver en rutt och inget annat. Det är olika avsikter med olika regelverk, och maskfrågan döljer det andra beslutet helt. Skriv ned vilket beteende du ville ha innan du lägger till en enda regel, för en klient som oväntat går ut via kontorslinjen är en överraskning som dyker upp på ett möte och inte i en logg.

En sista notering, utan koppling till åtgärden: PPTP är föråldrat och dess autentisering har varit trasig i åratal. Listan ovan förklarar fortfarande vad en PPP-länk gör, och samma resonemang gäller om du senare flyttar klienterna till en modern tunnel.