Dous portátiles marcan ao servidor PPTP dun equipo DD-WRT, cada un recibe un enderezo, e ningún pode facer ping ao outro. As carpetas compartidas nunca aparecen e o primeiro impulso é pensar que a máscara 255.255.255.255 que reparte o router debe estar mal. Non é a culpa, e cambiala non creará nin un só veciño novo. Faga as cinco comprobacións seguintes en orde e detéñase en canto unha falle, porque cada unha ten unha cura distinta.

Comprobación un: a /32 non é o fallo

PPTP transporta PPP, e unha ligazón PPP une exactamente dous extremos: o seu cliente e o servidor. Unha máscara de rede describe que enderezos comparten un segmento local, e aquí non hai segmento, só o par no outro extremo dun cable. Unha máscara de todo uns di precisamente iso, así que DD-WRT reparte o valor correcto para ese tipo de ligazón. O enderezo é un enderezo de par, non un enderezo de interface nunha LAN.

Unha máscara 255.255.255.0 pertence a un medio compartido con centos de dispositivos, e póndoa nunha interface PPP tampouco convertería o outro lado do túnel nun veciño.

Comprobación dous: lea os valores da páxina do servidor PPTP

Todos os axustes que importan están en Servizos, VPN, Servidor PPTP. Active o servidor, poña o enderezo do servidor no enderezo LAN do router e manteña o rango de clientes fóra do pool DHCP, para que un cliente que marca e unha máquina por cable non reciban o mesmo enderezo. En CHAP-Secrets engada unha liña por conta coa forma username * password *, sen espazos dentro do nome. Aplique e despois conecte cun perfil que nomee o router e unha desas contas.

Onde se detén o cliente dille que capa inspeccionar. Un cliente que se autentica pero non recibe enderezo é un problema de pool ou de segredos; un cliente que recibe un enderezo e non chega a nada é un problema de encamiñamento ou de cortalumes.

Comprobación tres: busque unha ruta entre os dous pares

Cada túnel que remata no router é a súa propia interface, normalmente ppp0, ppp1 e así sucesivamente. O tráfico dun cliente ao outro ten que encamiñarse entre esas interfaces, e o router ten que estar disposto a reenvialo. Execute ip route no router e busque unha ruta de host para cada par conectado que apunte á interface PPP correspondente. Se a un par lle falta a ruta, o túnel non está do todo levantado, diga o que diga a pantalla de estado do cliente.

Dúas rutas de host cara a dúas interfaces ppp separadas é a forma que quere antes de seguir adiante.

Comprobación catro: mire a cadea FORWARD, non a INPUT

O tráfico entre clientes reenvíase, non se acepta localmente, así que a cadea INPUT é o lugar equivocado. Execute iptables -L FORWARD -v -n e busque unha regra de descarte que atrape as interfaces PPP, ademais dos contadores de paquetes que mostran se chega algo á cadea. Unha política de descarte por defecto sen regra de aceptación para o tráfico do túnel produce exactamente o síntoma co que comezou: cada cliente só está ben, xuntos son invisibles o un para o outro.

Se os pings pequenos funcionan e as transferencias grandes atascan, o túnel estase fragmentando en lugar de bloquearse. PPTP sobre PPP normalmente quere unha MTU e unha MRU arredor de 1450, e deixalas en 1500 dá unha ligazón que supera os apretóns de man e falla con cargas reais.

Comprobación cinco: decida que debe facer o acceso a internet

Os clientes que deben navegar pola oficina necesitan tradución de orixe cara á interface WAN. Os clientes que só deben chegar á LAN necesitan unha ruta e nada máis. Son intencións distintas con conxuntos de regras distintos, e a pregunta da máscara agocha por completo esta segunda decisión. Anote que comportamento quería antes de engadir unha soa regra, porque un cliente que sae inesperadamente pola liña da oficina é unha sorpresa que aparece nunha reunión e non nun rexistro.

Unha última nota, allea á solución: PPTP está obsoleto e a súa autenticación leva anos rota. A lista de arriba segue explicando que fai unha ligazón PPP, e o mesmo razoamento vale se máis adiante move os clientes a un túnel moderno.

Artigos relacionados