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 пула, за да не получат dial-in клиент и кабелна машина един и същ адрес. Под 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 връзката и същите разсъждения важат, ако по-късно преместиш клиентите на модерен тунел.