Klienti PPTP na DD-WRT na sebe nevidí: pět kontrol

Dva notebooky se přihlásí na PPTP server na krabici s DD-WRT, každý dostane adresu, a ani jeden nedokáže pingnout ten druhý. Sdílené složky se nikdy neobjeví a první nápad je, že maska 255.255.255.255, kterou router rozdává, musí být špatně. Není to příčina a její změna nevytvoří ani jednoho nového souseda. Projděte pět kontrol níže popořadě a skončete, jakmile některá selže, protože každá má jiný lék.

Kontrola první: /32 není chyba

PPTP přenáší PPP a linka PPP spojuje právě dva koncové body: váš klient a server. Maska sítě popisuje, které adresy sdílejí lokální segment, a tady žádný segment není, jen protějšek na druhém konci jednoho drátu. Maska samých jedniček říká přesně to, takže DD-WRT vydává správnou hodnotu pro tento typ linky. Adresa je adresa protějšku, ne adresa rozhraní v LAN.

Maska 255.255.255.0 patří na sdílené médium se stovkami zařízení, a její nasazení na rozhraní PPP také neudělá z druhé strany tunelu souseda.

Kontrola druhá: přečtěte hodnoty na stránce PPTP serveru

Všechna důležitá nastavení jsou ve Služby, VPN, PPTP server. Zapněte server, nastavte adresu serveru na LAN adresu routeru a držte rozsah klientů mimo DHCP pool, aby vytáčený klient a kabelový stroj nedostali stejnou adresu. Pod CHAP-Secrets přidejte jeden řádek na účet ve tvaru username * password *, bez mezer uvnitř jména. Použijte a potom se připojte profilem, který jmenuje router a jeden z těch účtů.

Kde se klient zastaví, napoví, kterou vrstvu prohlížet. Klient, který se ověří, ale nedostane adresu, je problém poolu nebo tajemství; klient, který adresu dostane a nic nedosáhne, je problém směrování nebo firewallu.

Kontrola třetí: hledejte trasu mezi dvěma protějšky

Každý tunel ukončený na routeru má vlastní rozhraní, obvykle ppp0, ppp1 a tak dál. Provoz od jednoho klienta k druhému se musí směrovat mezi těmito rozhraními a router ho musí být ochoten přeposílat. Spusťte ip route na routeru a hledejte hostitelskou trasu pro každý připojený protějšek, ukazující na odpovídající rozhraní PPP. Chybí-li protějšku trasa, tunel není plně nahoře, ať obrazovka stavu klienta tvrdí cokoli.

Dvě hostitelské trasy na dvě samostatná rozhraní ppp je tvar, který chcete mít, než půjdete dál.

Kontrola čtvrtá: prohlédněte řetěz FORWARD, ne INPUT

Provoz mezi klienty se přeposílá, nepřijímá lokálně, takže řetěz INPUT je špatné místo. Spusťte iptables -L FORWARD -v -n a hledejte pravidlo zahazování, které chytá rozhraní PPP, plus počítadla paketů, která ukazují, zda do řetězce vůbec něco dorazí. Výchozí politika zahazování bez pravidla přijetí pro tunelový provoz dává přesně ten symptom, se kterým jste začali: každý klient sám je v pořádku, společně jsou pro sebe neviditelní.

Když malé pingy procházejí a velké přenosy se zadrhávají, tunel se spíš fragmentuje než blokuje. PPTP přes PPP obvykle chce MTU a MRU kolem 1450, a ponechání na 1500 vám dá linku, která projde handshake a selže na skutečné zátěži.

Kontrola pátá: rozhodněte, co má dělat přístup k internetu

Klienti, kteří mají prohlížet přes kancelář, potřebují překlad zdrojové adresy směrem k rozhraní WAN. Klienti, kteří mají dosáhnout jen na LAN, potřebují trasu a nic jiného. To jsou různé záměry s různými sadami pravidel a otázka masky tuhle druhou volbu úplně zakrývá. Napište si, jaké chování jste chtěli, než přidáte jediné pravidlo, protože klient, který nečekaně vyjde kancelářskou linkou, je překvapení, které vyplave na poradě, ne v logu.

Poslední poznámka, nesouvisející s opravou: PPTP je zastaralé a jeho autentizace je roky rozbitá. Seznam výše pořád vysvětluje, co linka PPP dělá, a stejná úvaha platí, když klienty později přesunete na moderní tunel.