Кліенты PPTP на DD-WRT не бачаць адзін аднаго: пяць праверак

Два ноўтбукі падключаюцца да сервера PPTP на прыладзе DD-WRT, кожны атрымлівае адрас, і ніводзін не можа дапінгаваць другі. Агульныя папкі не з’яўляюцца, і першая думка — што маска 255.255.255.255, якую выдае роўтар, абавязкова памылковая. Гэта не прычына, і яе змена не створыць ніводнага новага суседа. Прайдзіце пяць праверак ніжэй па парадку і спыніцеся, як толькі адна з іх праваліцца, бо ў кожнай свае лекі.

Праверка першая: /32 — не памылка

PPTP пераносіць PPP, а спасылка PPP злучае роўна два канцы: ваш кліент і сервер. Маска падсеткі апісвае, якія адрасы дзеляць лакальны сегмент, а тут сегмента няма — толькі партнёр на другім канцы аднаго дроту. Маска з адных адзінак кажа менавіта гэта, таму DD-WRT выдае слушнае значэнне для гэтага тыпу спасылкі. Адрас — гэта адрас партнёра, а не адрас інтэрфейса ў LAN.

Маска 255.255.255.0 належыць асяроддзю супольнага доступу з сотнямі прылад, і калі паставіць яе на інтэрфейс PPP, другі бок тунеля таксама не стане суседам.

Праверка другая: прачытайце значэнні на старонцы сервера PPTP

Усе значныя налады знаходзяцца ў раздзеле Службы, VPN, Сервер PPTP. Уключыце сервер, задайце адрас сервера як адрас роўтара ў LAN і трымайце дыяпазон кліентаў па-за пулам DHCP, каб кліент, які дазвоньваецца, і правадная машына не атрымалі адзін і той жа адрас. У CHAP-Secrets дадайце па адным радку на кожны ўліковы запіс у выглядзе username * password *, без прабелаў унутры імені. Прымяніце, потым падключыцеся профілем, у якім указаны роўтар і адзін з гэтых запісаў.

Месца, дзе кліент спыняецца, падказвае, які ўзровень правяраць. Кліент, які праходзіць аўтэнтыфікацыю, але не атрымлівае адрас, — гэта праблема пула або сакрэтаў; кліент, які атрымлівае адрас і нічога не дасягае, — праблема маршрутызацыі або міжсеткавага экрана.

Праверка трэцяя: шукайце маршрут паміж двума партнёрамі

Кожны тунель, што заканчваецца на роўтары, — гэта свой інтэрфейс, звычайна ppp0, ppp1 і далей. Трафік ад аднаго кліента да другога мусіць маршрутызавацца паміж гэтымі інтэрфейсамі, і роўтар павінен быць гатовы яго перасылаць. Выканайце ip route на роўтары і пашукайце маршрут да хоста для кожнага падключанага партнёра, які паказвае на адпаведны інтэрфейс PPP. Калі ў партнёра няма маршруту, тунель не ўзняты цалкам, што б ні сцвярджаў экран стану кліента.

Два маршруты да хостаў праз два асобныя інтэрфейсы ppp — менавіта той выгляд, які патрэбны, перш чым ісці далей.

Праверка чацвёртая: глядзіце ланцуг FORWARD, а не INPUT

Трафік ад кліента да кліента перасылаецца, а не прымаецца лакальна, таму ланцуг INPUT — няправільнае месца для пошуку. Выканайце iptables -L FORWARD -v -n і пашукайце правіла скіду, якое ловіць інтэрфейсы PPP, а таксама лічыльнікі пакетаў, што паказваюць, ці наогул нешта даходзіць да ланцуга. Палітыка скіду па змаўчанні без правіла прыёму для трафіку тунеля дае менавіта той сімптом, з якога вы пачалі: кожны кліент паасобку ў парадку, а разам яны нябачныя адзін для аднаго.

Калі малыя пінгі праходзяць, а вялікія перадачы затыкаюцца, тунель фрагментуецца, а не блакуецца. PPTP праз PPP звычайна хоча MTU і MRU каля 1450, а калі пакінуць іх на 1500, атрымаеце спасылку, якая праходзіць рукапоціскі і зрываецца на рэальных нагрузках.

Праверка пятая: вырашыце, што павінен рабіць выхад у інтэрнэт

Кліентам, якія павінны хадзіць у сетку праз офіс, патрэбна трансляцыя крынічнага адраса ў бок інтэрфейса WAN. Кліентам, якім патрэбна толькі LAN, патрэбны маршрут і больш нічога. Гэта розныя намеры з рознымі наборамі правілаў, і пытанне маскі цалкам хавае гэтае другое рашэнне. Запішыце, якія паводзіны вы хацелі, перш чым дадаць хоць адно правіла, бо кліент, што нечакана выходзіць праз офісную лінію, — гэта сюрпрыз, які ўсплывае на нарадзе, а не ў журнале.

Апошняя заўвага, не звязаная з выпраўленнем: PPTP састарэлы, і яго аўтэнтыфікацыя зламаная ўжо гады. Пералік вышэй усё яшчэ тлумачыць, што робіць спасылка PPP, і тыя ж развагі дзейнічаюць, калі пазней перавядзяце кліентаў на сучасны тунель.