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 врската, а истото размислување важи ако подоцна ги преместите клиентите на современ тунел.