Tuneles PPP con MikroTik RouterOS v6.40.3.01

MAE-VPN-PPP MikroTik Administration Engineer

Túneles PPP con MikroTik RouterOS v6.40.3.01 Libro de Estudio & Manual de Laboratorio ABC Xperts ® Network Xperts ® Academy Xperts ® Derechos de autor y marcas registradas Todos los derechos de autor y marcas registradas son propiedad del titular de los derechos de autor respectivo Derechos de autor © por Academy Xperts Todos los derechos reservados. Ninguna parte de este libro puede ser reproducido, almacenado, o transmitido por cualquier medio ya sea este un auditorio, medio gráfico, mecánico, o electrónico sin el permiso escrito del autor, excepto en los casos en que se utilicen breves extractos para usarlos en artículos o revisiones. La reproducción no autorizada de cualquier parte de este libro es ilegal y sujeta a sanciones legales.

RouterOS v6.40.3.01 – MAE-VPN-PPP, Túneles PPP con MikroTik RouterOS

Academy Xper t s i

Tabla de Contenido Prólogo ................................................................................................................................................................. ii

Resumen .......................................................................................................................................................................... iiiAudiencia .......................................................................................................................................................................... iiiConvenciones usadas en este libro .................................................................................................................................. iiiComentarios y preguntas ................................................................................................................................................. iii

Partners de Academy Xperts en Latinoamérica .............................................................................................. ivEmpresas Asociadas ........................................................................................................................................................ ivUniversidades e Institutos Superiores ............................................................................................................................... vDeseas convertirte en Academia o ser Partner de Academy Xperts? .............................................................................. vUn poco de Historia (Costa Rica) ..................................................................................................................................... vi

Cubriendo un País con MikroTik. ............................................................................................................................. viDetalle de cambios en las últimas versiones de RouterOS ............................................................................................. vii

6.40.3 (2017-Sep-01 07:40) .................................................................................................................................... vii6.40.2 (2017-Ago-08 13:13) ................................................................................................................................... viii6.40.1 (2017-Ago-03 12:37) ................................................................................................................................... viii

Capítulo 1: Introducción ................................................................................................................................... 10Encapsulación ........................................................................................................................................................ 11

RouterOS y Túneles ....................................................................................................................................................... 12/ppp profile (perfiles de usuario) ..................................................................................................................................... 12/ppp secret (base de datos de usuario) .......................................................................................................................... 15/ppp active (usuarios activos) ......................................................................................................................................... 16/ppp aaa (AAA remoto) ................................................................................................................................................... 16/ppp client (cliente PPP) ................................................................................................................................................. 17/ip pool ............................................................................................................................................................................ 18

Capítulo 2: PPTP ................................................................................................................................................ 20PPTP Client (cliente pptp) ...................................................................................................................................... 22PPTP Server (servidor pptp) .................................................................................................................................. 23

En Resumen ................................................................................................................................................................... 23Cómo trabaja PPTP ................................................................................................................................................ 23Detalles técnicos de PPTP ..................................................................................................................................... 24Ventajas de PPTP .................................................................................................................................................. 24Desventajas de PPTP ............................................................................................................................................ 24

Capítulo 3: L2TP ................................................................................................................................................ 25L2TP Client (cliente l2tp) ........................................................................................................................................ 25L2TP Server (servidor l2tp) .................................................................................................................................... 26

En Resumen ................................................................................................................................................................... 27Cómo trabaja L2TP ................................................................................................................................................ 27Detalles técnicos de L2TP ...................................................................................................................................... 27Ventajas de L2TP ................................................................................................................................................... 27Desventajas de L2TP ............................................................................................................................................. 27

Capítulo 4: PPPoE ............................................................................................................................................. 28Operación PPPoE .................................................................................................................................................. 28Tipos de paquetes utilizados .................................................................................................................................. 29MTU ........................................................................................................................................................................ 29pppoe client (Cliente PPPoE) ................................................................................................................................. 30Status ..................................................................................................................................................................... 30Scanner .................................................................................................................................................................. 31Configuración del Server PPPoE (Concentrador de Acceso) ................................................................................ 32


Academy Xper t s ii

Prólogo MikroTik es una empresa que nace en Latvia (Letonia) en 1996 con el claro objetivo de proveer un sistema operativo de red altamente robusto y eficiente al cual llamó RouterOS en 1997. La evolución del mismo llevó a la creación y lanzamiento al mercado en el 2002 de un hardware que aprovechara al máximo sus grandes capacidades de multiprocesamiento simétrico y multi-núcleo, este hardware es el RouterBOARD. A lo largo de los años a partir del nacimiento del Internet, los administradores de red hemos visto desfilar varios fabricantes por nuestros racks, habiendo estado siempre Cisco como referente, sin embargo, siempre había representado un costo más o menos importante a la hora de implementar una solución de red ruteada en especial si se trataba de un ISP/WISP. No es sino hasta hace una década aproximadamente en que MikroTik se empieza a hacer conocer en Latinoamérica y varios emprendedores y por sobre entusiastas, se vuelcan a la implementación de soluciones basadas en RouterOS y RouterBOARD. Claros ejemplos de ello son nuestros grandes amigos de Index México (Ezequiel García) y REICO Costa Rica (Miguel Solís) quienes se volcaron a confiar en los productos ofrecidos por MikroTik. Es muy interesante y gratificante conversar con ellos y escuchar los relatos sobre los primeros pasos del fabricante letón en tierras americanas. Estoy convencido de que MikroTik llegó no solo para quedarse sino para formar una parte muy importante en la historia del networking y de las telecomunicaciones. De hecho, cientos de miles (quizá millones a esta fecha, Mayo 2015) obtienen su internet de banda ancha a un bajo costo a través de una red ruteada gracias a que los proveedores de Internet, pequeños y medianos, pueden estructurar e implementar redes sumamente complejas y completas usando equipos MikroTik. Las soluciones en RouterOS y RouterBOARD no se han quedado estancadas en las empresas de Telecom pequeñas, sino que han ido escalando en credibilidad en las empresa medianas y grandes en Latinoamérica, rompiendo paradigmas de fabricantes y costos de implementación. Este libro nace como un aporte a la comunidad tecnológica de habla hispana y latinoamericana que ha decidido incursionar en MikroTik y desea obtener un conocimiento formal. De igual manera queremos que esta guía constituya una fuente importante de aprendizaje para quienes empiezan a realizar sus primeras configuraciones en RouterOS. Mauro Escalante CEO Academy Xperts CEO Network Xperts


Academy Xper t s iii

Resumen Audiencia Las personas que leen este libro deben estar familiarizados con:

• Operaciones de red en Capa 2 • Conjunto de protocolos IP, incluyendo TCP. UDP e ICMP

Este libro está dirigido a: • Ingenieros y Técnicos en Redes, Telecomunicaciones y afines, que desea implementar y dar soporte a:

§ Redes Corporativas § Clientes WISP e ISP

• Ingenieros de Redes involucrados en actividades de pre-venta y post-venta en soporte e instalación de redes corporativa y PYMES

• Ingenieros de Redes, Administradores de Red, Técnicos en Soporte de Redes, y Técnicos de Soporte a Usuario (Help Desk)

Convenciones usadas en este libro En este libro se utilizarán las siguientes convenciones tipográficas: Itálicas

Indica comandos, direcciones de correo, claves, mensajes de error, nombres de archivos, énfasis, y el primer uso de términos técnicos

Courier new

Indica direcciones IP y ejemplos de línea de comando Courier new en itálica

Indica texto que puede ser reemplazado Courier new en negrita

Indica datos de entrada del usuario Este icono significa un consejo, sugerencia, o una nota general.

Este icono indica una advertencia o precaución.

Comentarios y preguntas Puede enviar sus comentarios y preguntas sobre este libro por correo tradicional a la siguiente dirección:

Network Xperts S.A. Av. Juan T. Marengo y J. Orrantia Edificio Professional Center, Piso 5, Ofic. 507 Guayaquil, ECUADOR +593-4-600-8590 +593-9-9535-2132

A través del sitio web y por medio de su usuario y contraseña, tendrá acceso a las actualizaciones, ejemplos, e información adicional: http://cursos.abcxperts.com Puede enviarnos sus comentarios o preguntas técnicas sobre este libro enviándonos un email a: [email protected] Para más información sobre libros, conferencias, centros de recursos, y la red educativa de Academy Xperts, visite nuestros Websites y canal de YouTube http://www.abcxperts.com

http://www.academyxperts.com http://www.youtube.com/abcxperts


Academy Xper t s iv

Partners de Academy Xperts en Latinoamérica Nuestro recorrido por América Latina nos ha comprometido de una manera muy importante con nuestros alumnos, amigos y socios. Y este compromiso conlleva la enorme responsabilidad de estar siempre a la vanguardia, de presentar a nuestros estudiantes el mejor y más completo material de estudio & laboratorio, y lo que es muy importante… que el contenido siempre esté actualizado. Nos encantaría estar presente en cada uno de los 15 países y las más de 65 ciudades que recorremos todos los años, pero el tiempo y la disponibilidad física nos es un obstáculo. Por este motivo hemos desarrollado un esquema de Partnership con empresas, universidades e institutos superiores en diferentes países que trabajan junto con nosotros en sus respetivos ambientes, y que entregan a sus estudiantes el contenido y el acceso a la suscripción de este libro (y todos sus recursos) por un cómodo valor.

Empresas Asociadas


Academy Xper t s v

Universidades e Institutos Superiores

Deseas convertirte en Academia o ser Partner de Academy Xperts? • Si eres Universidad o Instituto Superior que cuenta con el respectivo acuerdo ministerial de tu país, puedes

optar por convertirte en una Academia MikroTik. Escríbenos a [email protected] para darte más información. • Si eres Trainer Partner y quieres explotar junto a tus alumnos nuestro material y portal de capacitación, te

invitamos escribirnos a [email protected] para proporcionarte los detalles. • Si deseas que organicemos cursos en tu ciudad/país de residencia, escríbenos a [email protected]


Academy Xper t s vi

Un poco de Historia (Costa Rica) Cubriendo un País con MikroTik. En el año 1998, estando en una empresa de servicios públicos en Costa Rica, el Ing. Miguel Solís en conjunto con el Ing. Paulino Solano, comenzaron a utilizar MikroTik con gran éxito en las telecomunicaciones de esta empresa. Se lograron 2 Mbps en una distancia de 8 Km, una velocidad record para aquellos tiempos en que la velocidad rondaba los 256 Kbps. En esta empresa de Servicios Públicos, se logró la interconexión de 52 sucursales mediante tecnología inalámbrica, todas bajo la misma marca MikroTik y su sistema operativo RouterOS. Dado el éxito alcanzado en este proyecto, ambos ingenieros en conjunto con uno más llamado Olman González, decidieron formar una empresa que se dedicara a solventar los problemas de telecomunicaciones en donde el cobre no fuera factible o se necesitara más velocidad. Esta empresa fue nombrada Redes Inalámbricas de Costa Rica S.A (REICO). Es así como a la fecha (Julio 2015), REICO, con solo Miguel Solís como propietario, tiene el liderato en telecomunicaciones inalámbricas en el país Centroamericano Costa Rica. REICO posee más de 3,800 Km de red troncal inalámbrica y más de 80,000 Km de red de acceso. Posee más de 100 radio bases instaladas estratégicamente para alcanzar una cobertura de más del 80% del territorio y a más del 90% de la población. La empresa se dedica 100% a proveer transporte de datos corporativos y sirve a sectores financieros, agroindustriales, turísticos, comerciales, etc. Su plataforma tiene una particularidad única en el mundo, con sus más de 1,000 clientes corporativos y empresariales y sus más de 1,500 equipos de acceso, CPE, transporte, Core secundario y Core primario: EL 100% SON MARCA MIKROTIK. REICO es un ejemplo del gran potencial que tiene MikroTik y RouterOS ya que esta empresa compite en el mercado con grandes de las telecomunicaciones y aun así mantiene una posición privilegiada, siendo el cuarto operador en Costa Rica en importancia en Transporte de Datos Corporativos, por debajo de ICE, Tigo y de RACSA pero por encima de Claro, Telefónica, Cables & Wireless, etc. Esto según el último informe de Estadísticas del Sector de Telecomunicaciones de Costa Rica 2014.

Texto desarrollado por el Ing. Miguel Solís, a quien agradezco por su aporte histórico sobre los inicios de MikroTik en Latinoamérica.


Academy Xper t s vii

Detalle de cambios en las últimas versiones de RouterOS Para una revisión del histórico de cambios en la versión 6.x le recomendamos visitar el siguiente link: http://abcxperts.com/index.php/bitacora-de-cambios

6.40.3 (2017-Sep-01 07:40) dhcpv6-server • No se libera la dirección del binding estático del pool después que el server lo remueve

export • Se corrige el export "/system routerboard" (se introdujo en v6.40.1) • Se corrige el export de la configuración relacionada con PoE-OUT

ike1 • Se corrige un problema en el iniciador de comparación ID para NAT-OA

led • Se corrigieron los triggers "on" y "off" cuando se seleccionaban múltiples LEDs • Se corrigió el LED ether 1 del RB711UA (se introdujo en v6.38rc16)

lte • No se muestra el modem USB LTE en el menú "/port" • Se corrigió un problema de variación ethernet cuando el LTE establece conexión • Se corrigió los gráficos SXT LTE en QuickSet • Se mejoró la confiabilidad de los módems USB LTE

poe-out • Se corrigió un problema de reboot del router después de que cambia el "poe-out-status" (estatus del ppoe-out)

rb1100ahx4 • Se corrigió un problema en la decriptación de paquete fragmentado en la aceleración por hardware cuando un

fragmento es menor a 64 bytes rb750gr3 • Se muestra la advertencia y no se permite utilizar la característica "protected-bootloader" si el "factory-

firmware" es anterior a la versión v3.34.4 routerboard • Se agregó el soporte "mode-button" para el RB750Gr3 (únicamente disponible por CLI)

ssh • No se ejecuta el comando si inicia con el símolo "-"

traffic-flow • Se corrigió un problema de reboot cuando la dirección IPv6 se ha configurado como dirección destino sin que esté

activo el paquete IPv6 userman • Se corrigió un problema en la actualización de "limitation" y "profile-limitation" • Se corrigió un problema en el procesamiento del paquete CoA después de que cambia la configuración en "/tool

user-manager router" webfig • Permite abrir la entrada de la tabla incluso si la tabla no está ordenada por # (se introdujo en v6.40);


Academy Xper t s viii

• Se permite de-configurar "rate-limit" para las reservas (leases) DHCP winbox • Se agregó la posibilidad de definir "comment" para las entradas "/routing bgp network" • No se muestra la información relacionada con FAN el menú "/system health" para los dispositivos que no lo tienen • No se muestra el menu LCD para los dispositivos que no lo tienen • Se corrigió la actualización de la tabla ARP después de que la entrada cambia el estado a incomplete (incompleto)

wireless • Se agregó las configuraciones del país "russia3" • Se agregó la información del dominio regulatorio New Zealand para enlaces P2P • Se actualize la información del dominio regulatorio de China y New Zealand

www • Se corrigió los servicios Web que no responden (se introdujo en v6.40);

6.40.2 (2017-Ago-08 13:13) dhcpv6-client • Se corrigió el orden de evaluación IA

led • Se corrigió el parámetro "modem-signal" en los LEDs (se introdujo en v6.40)

pppoe-client • Se corrigió un problema de detección incorrecta MRU sobre las interfaces VLAN

rb2011 • Se corrigió un posible problema de parpadeo LCD con el LED ethernet (se introdujo en v6.40)

sfp • Se corrigió un problema de lecturas de temperatura inválidas cuando el ambiente de temperatura está bajo 0C

winbox • Se agregaron configuraciones de certificado • Se agregó soporte a la lista de certificado CRL • No se muestra el menú LCD para dispositivos que no o tienen • Se oculta los Parámetros "level" y "tunnel" para los templates de políticas IPSec • Se oculta la velocidad del ventilador (FAN) si es 0RPM

6.40.1 (2017-Ago-03 12:37) bonding • Se mejoró la confiabilidad cuando se remueve la interface bonding

chr • Se corrigió un problema de una falsa advertencia cuando se realiza el reboot luego el upgrade

dhcpv6-client • No se ejecuta el cliente DHCPv6 cuando el paquete IPv6 está deshabilitado

export • Se corrigió un problema en el export de diferentes parámetros cuando se espera un rango numérico o un string

constante firewall • Se remueve adecuadamente la entrada "address-list" después de que termina el timeout

interface • Se mejoró el manejo de cambio de estado de la interface cuando múltiples interfaces son afectadas al mismo tiempo

lte • Se corrigió un problema en que el LTE no pasaba ningún tráfico mientras estaba en estado de ejecución

ovpn-client • Se corrigió un problema en uso del netmask incorrecto para rutas empujadas (pushed) (se introdujo en v6.40)

pppoe-client • Se corrigió un problema en un paquete PADT formado incorrectamente

rb2011


Academy Xper t s ix

• Se corrigió un posible problema de parpadeo LCD en el LED ethernet (se introdujo en v6.40) rb922 • Se recuperó la interface Wireless perdida en algunos boards

torch • Se corrigió un problema en el Torch en túneles PPP (se introdujo en v6.40);

trafficgen • Se corrigió un problema al mostrar estadísticas incorrectas de "lost-ratio" después de múltiples secuencias

winbox • Se agregó las opciones "none-dynamic" y "none-static" para el parámetro "address-list-timeout" en las

reglas de NAT, Mangle y RAW

RouterOS v6.40.3.01 – MAE-VPN-PPP, Túneles PPP con MikroTik RouterOS, Capítulo 1: Introducción

Academy Xper t s 10

Capítulo 1: Introducción Los túneles son una forma de ampliar (extender) una red privada a través de una red pública (como Internet). A los Túneles también se les conoce como VPNs (Virtual Private Network = Redes Privadas Virtuales).

• El concepto de seguridad se asocia con VPN. Es recomendable ya que no se desea que el tráfico de los usuarios vaya a través de redes que no son seguras

Se llama "virtual" porque depende del uso de conexiones virtuales, es decir, conexiones temporales que no tienen presencia física real, sino que consisten en paquetes enrutados sobre varios equipos en Internet. Las conexiones virtuales seguras se crean entre:

• Dos equipos • Un equipo y una red • O dos redes.

Se conoce como túnel o tunneling a la técnica que consiste en encapsular un protocolo de red sobre otro (protocolo de red encapsulador) creando un túnel de información dentro de una red de computadoras. El uso de esta técnica persigue diferentes objetivos, dependiendo del problema que se esté tratando, como por ejemplo la comunicación de islas en escenarios multicast, la redirección de tráfico, etc. La técnica de tunelizar se suele utilizar para trasportar un protocolo determinado a través de una red que, en condiciones normales, no lo aceptaría. Otro uso de la tunelización de protocolos es la creación de diversos tipos de redes privadas virtuales. El establecimiento de dicho túnel se implementa incluyendo una PDU (Protocol Data Unit = Unidad de Datos de Protocolo) determinada dentro de otra PDU con el objetivo de transmitirla desde un extremo al otro del túnel sin que sea necesaria una interpretación intermedia de la PDU encapsulada. De esta manera se encaminan los paquetes de datos sobre nodos intermedios que son incapaces de ver en claro el contenido de dichos paquetes. El túnel queda definido por los puntos extremos y el protocolo de comunicación empleado, que entre otros, podría ser SSH. Así, el protocolo A es encapsulado dentro del protocolo B, de forma que el primero considera al segundo como si estuviera en el nivel de enlace de datos. Es importante recordar que cuando las capas de TCP/IP están en diferentes sistemas, no existe una comunicación directa entre cada capa, sino únicamente a través de las capas físicas. Esto significa que todos los datos de una aplicación deben seguir el flujo a través de todas las capas del modelo TCP/IP hasta el destino, y de igual manera en el proceso de retorno. Estos datos se conocen como SDU (Service Data Unit = Unidad de Datos de Servicio). Cada capa, en el sistema de envío, agrega información a los datos que recibe de la capa superior y la pasa a la capa inferior, a excepción de la capa física, que no tiene capas inferiores y tiene que enviar los bits en una forma apropiada para el enlace de comunicaciones utilizado. Del mismo modo, cada capa del sistema receptor desenvolviendo el mensaje recibido, a menudo coocido como PDU (Protocol Data Unit = Unidad de Datos de Protocolo), examinando cada capa, utilizando y desnudando la información que necesita para completar su tarea, y pasando el resto hasta el siguiente capa, a excepción de la capa de aplicación, que pasa lo que queda en el propio programa de aplicación. Por ejemplo, la capa de Enlace de Datos (capa 2) elimina la envoltura destinada a ella, la utiliza para decidir qué debe hacer con esta unidad de datos y, a continuación, pasa el resto hasta la Capa de Red (Capa 3).

Las 3 capas más bajas del modelo TCP/IP (conocidas como Capas de Soporte de Red) deben estar presentes y ser funcionales en todos los sistemas, independientemente del rol del sistema final o del nodo intermedio. La Capa de Transporte enlaza las capas superior e inferior. Esta capa se puede utilizar para asegurar de que lo que se envió fue lo que se recibió, y de que lo que se ha enviado es útil para quien recibe (receptor). Para que esto funcione existe un proceso que se conoce como Encapsulación.


Academy Xper t s 11

La encapsulación (de la información) de una capa dentro de otra capa es un punto clave en la manera en que trabaja TCP/IP. Encapsulación Cada capa realiza encapsulación paa agregar información que su contraparte (peer) necesita en el lado receptor. La capa de red agrega una cabecera a la información que recibe de la capa de transporte, pasa toda esta unidad de datos a la capa de Enlace de datos. En el lado receptor, la Capa de Red analiza la información de control que generalmente está en la cabecera, y pasa el remanente a la capa de transporte para su posterior procesamiento. Esto es lo que se conoce como encapsulación ya que una capa no tiene idea ni conocimiento del PDU de las otras capas. EL PDU suele recibir diferentes nombres dependiendo de la capa en la que se encuentre. La excepción a esta regla general es la capa de Enlace de Datos, la cual agrega una cabecera (header) y un arrastre (trailer) a los datos que recibe de la Capa de Red (capa 3).

El flujo de encapsulación TCP/IP es el que se muestra a continuación. Es importante notar que en el medio de transmisión o en el enlace de comunicación, existen únicamente bits, y que algunos bits “extras” son agregados por el enlace de comunicación para sus propios propósitos.

Cada PDU en las otras capas como datos (data) para su capa, y las cabeceras se abrevian basado en el nombre de la capa (por ejemplo, TH = Transport Header, NH = Network Header). La excepción es la Capa de Enlace de Datos (capa 2) en la que se observa un Trailer (Trl = Trailer) y una Cabecera (Hdr = Header). Los PDUs son relevantes en relación a cada una de las 4 capas del modelo OSI en la siguiente manera:

• El PDU de la Capa 1 (capa física) es el bit, tambien conocido como símbolo (o “stream”) • El PDU de la Capa 2 (capa de enlace de datos) es el frame • El PDU de la Capa 3 (capa de red) es el paquete • El PDU de la Capa 4 (capa de transporte) es el segmento (para TCP) o datagrama (para UDP)

Ejemplos de protocolos tunelizados • L2TP (Layer 2 Tunneling Protocol) • MPLS (Multiprotocol Label Switching) • PPTP (Point-to-Point Tunneling Protocol) • PPPoE (point-to-point protocol over Ethernet) • PPPoA (point-to-point protocol over ATM)


Academy Xper t s 12

• IPSec (Internet Protocol security) • IEEE 802.1Q (Ethernet VLANs) • 6to4 (IPv6 over IPv4 as protocol 41)

Túneles PPP dentro del mapa de Protocolos TCP/IP

RouterOS y Túneles

MikroTik RouterOS provee funcionalidad escalable de Autenticación, Autorización y Contabilización

• AAA = Authentication Authorization Accounting (Contabilización) La autenticación local se logra usando una Base de Datos de Usuario y una Base de Datos de Perfil (profile). La configuración del usuario está compuesta por el registro del respectivo usuario (tomado de la Base de Datos de Usuario), el ítem asociado de la Base de Datos de Perfil (profile) y el ítem en la base de datos de Perfil en cual está configurado como default para un servicio dado al que el usuario está autenticando. Las configuraciones del Perfil por default de la base de Datos del Perfil, tienen la prioridad más baja, mientras que las configuraciones de los registros de acceso de usuario de la Base de Datos de Usuario tiene la más alta prioridad con la única excepción de que siendo una dirección IP particular toma precedencia sobre los Pools de direcciones IP en las configuraciones local-address y remote-address. El soporte para la autenticación RADIUS le proporciona al ISP o al administrador de red la habilidad para manejar el acceso y la contabilidad de usuarios PPP desde un solo servidor a través de una gran red. MikroTik RouterOS tiene un Cliente RADIUS que puede autenticar conexiones PPP, PPPoE, PPTP, L2TP e ISDN. Los atributos recibidos del servidor RADIUS invalidan las configuraciones del Perfil (profile) por default, pero si algunos parámetros no son recibidos, entonces son tomados del Perfil por default respectivo

/ppp profile (perfiles de usuario) Los perfiles PPP se utilizan para definir los valores por default de los registros de usuario que se almacenan en el submenu /ppp secret. Las configuraciones /ppp secret de la Base de Datos de Usuario invalidan las configuraciones /ppp


Academy Xper t s 13

profile correspondientes, excepto que las direcciones IP simples siempre tienen precedencia sobre los Pool de direcciones IP cuando se especifican como parámetros en local-addres o remote-address.

Los PPP profiles representan los parámetros de configuración para ser utilizado por los clientes PPP, pero no limitados a:

• Dirección IP o Pool de direcciones (remotas o locales) • Compresión • Cifrado

/ppp profile (example from a client) add change-tcp-mss=yes name=Profile-external\ use-compression=yes use-encryption=yes use-vj-compression=no

/ppp profile (example from a server) add change-tcp-mss=yes local-address=192.168.222.1\ name=Profile-external remote-address=192.168.222.2 use-compression=yes\ use-encryption=yes use-vj-compression=no

add change-tcp-mss=no dns-server=192.168.5.1 local-address=192.168.5.1 name=Profile-internal\ remote-address=Pool-VPN use-compression=yes use-encryption=yes use-vj-compression=no

Parámetros • address-list (string; Default: ) .- Especifica el nombre del address-list a donde se agregarán las direcciones

asignadas PPP • bridge (string; Default: ) .- Nombre de la interface bridge a la que se agregará la interface ppp como un puerto

esclavo. Ambos puntos finales del tunel (server y cliente) deben estar en un bridge para que esto funcione. • change-tcp-mss (yes | no | default; Default: default) .- Permite cambiar la configuración de la conexión MSS

o yes : ajusta el valor de la conexión MSS o no : no ajusta el valor de la conexión MSS o default : obtiene este valor del perfil por default de la interface

• comment (string; Default: ) .- Campo para escribir un comentario • dhcpv6-pd-pool (string; Default: ) .- Nombre del Pool Ipv6 que se usará para el servidor DHCPv6-PD creado

dinámicamente cuando los clientes se conectan. • dns-server (IP; Default: ) .- Dirección IP del server DNS que se suministra a los clientes PPP • idle-timeout (time; Default: ) .- Especifica la cantidad de tiempo luego del cual el enlace se terminará si es que

no hay actividad presente. • incoming-filter (string; Default: ) .- Nombre del chain de firewall para paquetes entrantes. El chain especificado

obtiene el control para cada paquete que viene del cliente. El chain PPP debería ser agregado manualmente, y también deberían agregarse las reglas con action=jump jump-target=ppp a otros chains relevantes para que esta característica funcione.

• local-address (IP address | pool; Default: ) .- Especifica la dirección del túnel o el nombre del Pool del cual se asigna la dirección a la interface PPP local

• name (string; Default: ) .- Nombre del Perfil PPP • only-one (yes | no | default; Default: default) .- Define si es que un usuario está permitido tener más de una

conexión a la vez. o yes – Un usuario NO está permitido tener más de una conexión al mismo tiempo o no – El usuario está permitido a tener más de una conexión a la vez o default – Obtiene este valor del Perfil por default de la Interface

• outgoing-filter (string; Default: ) .- Nombre del chain de firewall para paquetes salientes. El chain especificado obtiene el control para cada paquete que va hacia el cliente. El chain PPP debería ser agregado manualmente, y también deberían agregarse las reglas con action=jump jump-target=ppp a otros chains relevantes para que esta característica funcione.

• rate-limit (string; Default: ) .- La limitación de velocidad desde el punto de vista del router se presenta en la siguiente forma (rx es el tráfico de subida del cliente, y tx es el tráfico de bajada del cliente):


Academy Xper t s 14

o rx-rate[/tx-rate] [rx-burst-rate[/tx-burst-rate] [rx-burst-threshold[/tx-burst-threshold] [rx-burst-time[/tx-burst-time] [priority] [rx-rate-min[/tx-rate-min]]]]

o Todas las velocidades están medidas en bits-por-segundo (bps), a menos que le siga el sufijo k (kilobits por segundo) o el sufijo M (megabits por segundo)

o Si no se especifica el tx-rate, entonces el rx-rate sirve también como tx-rate o Lo mismo aplica para tx-burst-rate, tx-burst-threshold y tx-burst-time. Si rx-burst-

threshold y tx-burst-threshold no se especifican (but burst-rate está especificado), rx-rate y tx-rate se utilizan como burst thresholds.

o Si rx-burst-time y tx-burst-time no se especifican, se utiliza 1s como default. La prioridad toma los valores 1..8, donde 1 representa a la prioridad más alta, y 8 la prioridad más baja.

o Si rx-rate-min y tx-rate-min no se especifican, entonces se utilizan los valores rx-rate y tx-rate o Los valores de rx-rate-min y tx-rate-min no pueden exceder a los valores rx-rate y tx-rate.

• remote-address (IP; Default: ) .- Especifica la dirección del túnel o el nombre del Pool del cual se asigna la dirección a la interface PPP remota

• remote-ipv6-prefix-pool (string | none; Default: none) .- Asigna el prefijo del Pool IPv6 al cliente e instala la correspondiente ruta IPv6.

• session-timeout (time; Default: ) .- Especifica el máximo tiempo de conexión que se puede establecer. Por default no se configura límite de tiempo.

• use-compression (yes | no | default; Default: default) .- Especifica si se usa compresión o no. Esta configuración no afecta los túneles OVPN

o yes – Habilita la compresión de datos o no – Deshabilita la compresión de datos o default – Obtiene este valor del Perfil por default de la Interface

• use-encryption (yes | no | default | require; Default: default) .- Especifica si se usa encriptación o no. Esta configuración no afecta los túneles OVPN

o yes – Habilita la encriptación de datos o no – Deshabilita la encriptación de datos o default – Obtiene este valor del Perfil por default de la Interface

• use-ipv6 (yes | no | default | require; Default: default) .- Especifica si se permite IPv6. Por default se habilita si es que el paquete IPv6 está instalado.

o yes – Habilita el soporte IPv6 o no – Deshabilita el soporte IPv6 o default – Obtiene este valor del Perfil por default de la Interface o require – Requiere explícitamente soporte IPv6

• use-mpls (yes | no | default | require; Default: default) .- Especifica si es que se permite MPLS sobre PPP o yes – Habilita el soporte MPLS o no – Deshabilita el soporte MPLS o default – Obtiene este valor del Perfil por default de la Interface o require – Requiere explícitamente soporte MPLS

• use-vj-compression (yes | no | default; Default: default) .- Especifica si es que se usa el algoritmo de compresión de cabecera Van Jacobson

o yes – Habilita la compresión de cabecera Van Jacobson o no – Deshabilita la compresión de cabecera Van Jacobson o default – Obtiene este valor del Perfil por default de la Interface

• wins-server (IP address; Default: ) .- Permite especificar la dirección IP del servidor WINs para suministrar a los clientes

Notas Importantes • Existen dos Perfiles por Default que no pueden ser removidos:

/ppp profile print Flags: * - default 0 * name="default" use-compression=no use-vj-compression=no use-encryption=no

only-one=no change-tcp-mss=yes 1 * name="default-encryption" use-compression=default use-vj-compression=default

use-encryption=yes only-one=default change-tcp-mss=default


Academy Xper t s 15

• Se debe usar el algoritmo de compresión Van Jacobson únicamente si es necesario, ya que se reducen las comunicaciones en canales malos o congestionados.

• Los argumentos incoming-filter y outgoing-filter agregan reglas de jump dinámicas al chain PPP, donde el argumento jump-target será igual al argumento incoming-filter o outgoing-filter en /ppp profile. Por lo tanto, el chain PPP debe ser agregado manualmente antes de que se cambien estos argumentos.

• El parámetro only-one se ignora si se usa la autenticación RADIUS • Si hay más de 10 conexiones PPP simultáneas, se recomienda apagar (off) la propiedad change-mss, y usar una

regla general de cambio MSS en la tabla de mangle, para reducir la utilización del CPU.

/ppp secret (base de datos de usuario) La Base de Datos de Usuario PPP almacena los registros de acceso de usuario PPP con el perfil de usuario PPP asignado a cada usuario. Los PPP secrets se encuentran en PPP servers y también podemos especificar los parámetros básicos y necesarios para autenticar a un cliente, tales como:

• Nombre: Identificación del usuario • Contraseña: contraseña del usuario • Servicio: el protocolo que está dando servicio (si de dejan en “any” el PPP secret autenticara al usuario a través de

algunos de estos servicios (PPPoE, L2TP, PPTP, etc.)) • Perfil: el subconjunto de configuración que utilizara este usuario. Los perfiles permiten parámetros a ser utilizados

por muchos usuarios sin tener que volver a escribir todo cada vez. Los clientes no utilizan PPP secrets como credenciales de autenticación. Se especifican en la interface del cliente PPP bajo los parámetros de “Usuario” y “Contraseña” /ppp secret add name=Pod4-external password=pod4-123 profile=Profile-external routes=192.168.4.0/24 add name=alain password=alain!! profile=Profile-internal

Parámetros

• caller-id (string; Default: ) .- Para PPTP y L2TP, este parámetro es la dirección IP desde la cual un cliente debe conectarse. Para PPPoE es la dirección MAC (escrito en letras mayúsculas) desde la cual un cliente debe conectarse. Para ISDN es el número del caller (que puede o no puede ser provisto por el operador) desde el cual el cliente debe llamar.

• comment (string; Default: ) .- Una corta descrición del usuario • disabled (yes | no; Default: no) .- Permite especificar si se usará un secret • limit-bytes-in (integer; Default: 0) .- Especifica la máxima cantidad de bytes que un cliente puede subir (upload)

en una sesión • limit-bytes-out (integer; Default: 0) .- Especifica la máxima cantidad de bytes que un cliente puede descargar

(download) • local-address (IP address; Default: ) .- Dirección IP que será configurada localmente en la interface PPP • name (string; Default: ) .- Nombre usado para la autenticación • password (string; Default: ) .- Contraseña (password) usada para la autenticación • profile (string; Default: default) .- Especifica qué perfil se utilizará • remote-address (IP; Default: ) .- Especifica la dirección IP que se asignará a la interface PPP remota • remote-ipv6-prefix (IPv6 prefix; Default: ) .- Prefijo IPv6 asignado al cliente PPP. El prefijo se agrega a la lista

de prefijo ND que permite la configuración automática de direcciones sin estado en una interface PPP. Esta opción está disponible desde la v5.0


Academy Xper t s 16

• routes (string; Default: ) .- Especifica las rutas que aparecen en el server cuando el cliente se conecta. El formato de la ruta es dst-address gateway metric (por ejemplo 10.1.0.0/24 10.0.0.1 1). Se peude especificar varias rutas separando con comas. Este parámetro será ignorado por OpenVPN

• service (any | async | isdn | l2tp | pppoe | pptp | ovpn | sstp; Default: any) .- Especifica el tipo de servicio que un usuario específico podrá utilizar.

/ppp active (usuarios activos) Este submenú permite minitorear los usuarios activos o usuarios conectados. Representa el estado actual de las conexiones.

Útil para depurar y verificar el funcionamiento correcto de sus túneles.

• /ppp active print mostrará todos los usuarios conectados actualmente • /ppp active print stats mostrará los bytes y paquetes recibidos

/ppp active print detail Flags: R - radius 0 name=”alain” service=pppoe caller-id=”28:D2:44:2C:06:EE”\ address=192.168.5.100 uptime=3m56s encoding=”MPPE128 statefull” session-id=0x81B00044\ limit-bytes-in=0 limit-bytes-out=0 1 name=”Pod4-external” service=pppoe caller-id=”D4:CA:6D:8E:1ª:97”\ address=192.168.222.2 uptime=37s encoding=”MPPE128 stateless” session-id=0x81B00045\ limit-bytes-in=0 limit-bytes-out=0 /ppp active print Flags: R – radius # NAME SERVICE CALLER-ID ADDRESS UPTIME ENCODING 0 alainpppoe 28:D2:44:2C:06:EE 192.168.5.100 4m12s MPPE128 statefull 1 Pod4-exte... pppoe D4:CA:6D:8E:1ª:97 192.168.222.2 53s MPPE128 stateless

Parámetros • address (IP address) .- La dfirección IP que el cliente obtiene del server • bytes (integer) .- Cantidad de bytes transferidos a través de esta conexión. La primera representa la cantidad de

tráfico transmitido desde el punto de vista del router, mientras que la segunda muestra la cantidad de tráfico recibido. • caller-id (string) .- Para PPTP y L2TP es la dirección IP desde la que el cliente está conectado. Para PPPoE es

la dirección MAC desde la que el cliente está conectado. • encoding (string) .- Muestra la encriptación y codificación (separado con “/” si es asimétrico) que está siendo usado

en esta conexión. • limit-bytes-in (integer) .- Máxima cantidad de bytes que el usuario está permitido enviar al router • limit-bytes-out (integer) .- Máxima cantidad de bytes que el usuario está permitido enviar al cliente • name (string) .- Nombre de usuario proporcionado en la fase de autenticación • packets (integer/integer) .- Cantidad de paquetes transferidos a través de esta conexión. La primera representa la

cantidad de tráfico transmitido desde el punto de vista del router, mientras que la segunda muestra la cantidad de tráfico recibido.

• service (async | isdn | l2tp | pppoe | pptp | ovpn | sstp) .- Tipo de servicio que el usuario está usando • session-id (string) .- Muestra el identificador de cliente único • uptime (time) .- Tiempo de actividad del usuario

/ppp aaa (AAA remoto) Las configuraciones en este menú permiten configurar la contabilización (accounting) y autenticación (authentication) RADIUS. La base de datos de usuario RADIUS se consulta únicamente si el nombre usuario (username) requerido no se encuentra en la base de datos de usuario local


Academy Xper t s 17

Parámetros

• accounting (yes | no; Default: yes) .- Habilita la contabilización (accounting) RADIUS • interim-update (time; Default: 0s) .- Intervalo de tiempo de actualización interino • use-radius (yes | no; Default: no) .- Habilita la autenticación de usuario vía RADIUS. Si no se encuentra le entrada

en la base de datos Secret Local, entonces el cliente será autenticado vía RADIUS.

/ppp client (cliente PPP)

Parámetros

• add-default-route (yes | no; Default: no) .- Especifica si se agrega la ruta por default para encaminar todo el tráfico sobre el túnel.

• allow (pap | chap | mschap1 | mschap2; Default: pap,chap,mschap1,mschap2) .- Especifica los protocolos permitidos a usar para la autenticación

• apn (string; Default: ) .- Nombre del Access Point (APN = Access Point Name) del Proveedor de Servicio • comment (string; Default: ) .- Nombre que describe el item • data-channel (integer; Default: 0) .- Especifica cuál de los canales de puertos es usado para transferir datos. • default-route-distance (integer; Default: 1) .- A partir de la v6.2, configura el valor distancia aplicado para la

ruta por default creada automáticamente, si es que también se ha seleccionado add-default-route • dial-command (string; Default: "ATDT") .- Comando dial que se va a usar. Por default se configura el modo del

tono de marcado • dial-on-demand (yes | no; Default: no) .- Habilita/deshabilita dial on demand • disabled (yes | no; Default: yes) .- Especifica si es que la interface esta deshabilitada o no. Por default está

deshabilitada • info-channel (integer; Default: 0) .- Especifica cuál de los canales de puerto (por channels) se utiliza para info • keepalive-timeout (integer [0..4294967295]; Default: 30s) .- Keepalive timeout PPP en segundos • max-mru (integer; Default: 1500) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). Tamaño

máximo del paquete que la interface PPP estará habilitada para recibir sin fragmentación de paquetes • max-mtu (integer; Default: 1500) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit). Tamaño

máximo del paquete que la interface PPP estará habilitada para enviar sin fragmentación de paquetes • modem-init (string; Default: "") .- String de inicialización del modem • mrru (disabled | integer; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el enlace. Si

un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel.

• name (string; Default: ) .- Nombre descriptivo de la interface • null-modem (yes | no; Default: no) .- Habilita/deshabilita el modo null-modem (cuando está habilitado, no se

envían cadenas de inicialización al modem) • password (string; Default: "") .- Contraseña (password) usada para autenticación • phone (string; Default: "") .- Número de teléfono para marcar (dial-out) • pin (string; Default: "") .- Código de Pin de las Tarjetas SIM • port (string; Default: "") .- Nombre del puerto Serial o USB donde está conectado el modem


Academy Xper t s 18

• profile (name; Default: default) .- Perfil PPP que se utiliza • remote-address (IP Address; Default: ) .- Dirección IP remota • use-peer-dns (yes | no; Default: yes) .- Usa las configuraciones DNS server del servidor remoto • user (string; Default: ) .- Nombre de usuario usado para autenticación

/ip pool El Pool IP define un rango de direcciones IP que es utlizado por el Server DHCP y también por los Servers Point-to-Point. Es decir que no sólo es utilizado para DHCP, sino que también se puede utilizar para los clientes PPP y Hotspot. Útil cuando una interface puede dar servicio a muchos clientes. Las direcciones se asignan a partir del Pool de forma automática. Rangos de IPs son listas de direcciones IP que no se repiten entre si y que se pueden asignar a los clientes a través de servicios (DHCP, PPP, Hotspot).

Parámetros

• name (name) .- El nombre del Pool • next-pool (name) .- Cuando la dirección se adquiere de un pool que no tiene direcciones libres, y la propiedad

next-pool está configurada a otro pool, entonces la siguiente dirección se obtendrá del next-pool • ranges (IP address) .- La lista de dirección IP de los rangos de dirección IP en la forma: desde1-hasta1,

desde2-hasta2, …, desdeN-hastaN. Por ejemplo, 10.0.0.1-10.0.0.27,10.0.0.32-10.0.0.47 Vamos a demostrar con un ejemplo. Usted tiene 50 ordenadores de la LAN corporativa y 50 que vienen desde VPN. /ip pool add name=Pool-PC ranges=192.168.5.50-192.168.5.99 add name=Pool-VPN ranges=192.168.5.100-192.168.5.149

Supongamos ahora que usted necesita agregar 50 equipos en el Pool de la LAN /ip pool print # NAME RANGES 0 Pool-PC 192.168.5.50-192.168.5.99 1 Pool-VPN 192.168.5.100-192.168.5.149 /ip pool set 0 ranges=192.168.5.50-192.168.5.99,192.168.5.150-192.168.5.199 /ip pool> print # NAME RANGES 0 Pool-PC 192.168.5.50-192.168.5.99 192.168.5.150-192.168.5.199 1 Pool-VPN 192.168.5.100-192.168.5.149

Asignaciones para un servicio • Un Pool puede ser asignado para diferentes servicios tales como DHCP, PPP y HotSpot. • Veremos la sintaxis más adelante

Pregunta: Cómo comunicamos las redes A y B?


Academy Xper t s 19

RouterOS v6.40.3.01 – MAE-VPN-PPP, Túneles PPP con MikroTik RouterOS, Capítulo 2: PPTP

Academy Xper t s 20

Capítulo 2: PPTP PPTP es un método de túnel desarrollado por Microsoft como una extensión a PPP, para acceso remoto a través de un servidor especializado. PPTP se encuentra definido en la RFC 2637, y es considerado un protocolo de Capa 2, lo que significa que la carga útil (payload) es el mismo frame en Capa 2, encriptado y precedido por una pequeña cabecera PPTP basada en extensiones de la cabecera (header) GRE (Generic Routing Encapsulation = Encapsulación de Ruteo Genérico) que se describe en RFC 2784. Este frame, con su cabecera (header) y tráiler (tráiler), se ubica dentro de otro paquete y se envía a través de la red entre un Concentrador de Acceso PPTP (PAC = PPTP Access Concentrator) y un Servidor de Red PPTP (PNS = PPTP Network Server), por lo tanto, PPTP es un protocolo Cliente/servidor. Los mensajes de control se intercambian por el puerto TCP 1723, y la encriptación es proporcionada por los mecanismos PPP subyacentes. Las claves de encriptación se generan de los procesos de autenticación, los cuales generalmente utilizan CHAP (Challenge Handshake Authentication Protocol) el cual es un mecanismo comunicación de 3 vías (three-way handshake) que utiliza contraseñas (passwords) encriptados. Este mecanismo está definido en RFC 1994. PPTP fue considerado un túnel relativamente seguro para transportar tráfico IP usando PPP, sin embargo, actualmente se lo considera como un método obsoleto para implementar una VPN debido a los diferentes problemas y vulnerabilidad de seguridad que se han encontrado. Estas vulnerabilidades están relacionadas con los protocolos de autenticación subyacentes de PPP, específicamente en el diseño del protocolo MPPE y en la integración entre MPPE y la autenticación PPP para el establecimiento de la clave (key) de sesión. En resumen, las vulnerabilidades son las siguientes:

• MS-CHAP-v1 es fundamentalmente inseguro. Existen herramientas que permiten extraer los hashes de contraseña NT de una captura de un intercambio MSCHAP-v1

• Cuando se utiliza MS-CHAP-v1, MPPE utiliza la misma clave (key) de sesión RC4 para la encriptación en ambas direcciones del flujo de comunicación. Esto puede ser criptoanalizado con métodos estándar haciendo XORing de los streams de cada dirección

• MS-CHAP-v2 es vulnerable a ataques por diccionario cuando se captura los paquetes de intercambio de respuesta. Existen herramientas que realizan este proceso de manera muy rápida.

• En 2012 se demostró que la complejidad de un ataque por fuerza bruta (brute-force attack) a una clave MS-CHAP-v2 es equivalente a un ataque por fuerza bruta en una simple clave DES. Un servicio en línea (on line) demostró que era capaz de desencriptar un passphrase (frase de contraseña) MS-CHAP-v2 MD4 en 23 horas.

• MPPE utiliza el cifrado de stream RC4 para la encriptación. Puesto que no existe un método de autenticación del stream cifrado, el texto cifrado es vulnerable a un ataque bit-flipping. Es decir, que un atacante podría modificar el stream que está circulando y ajustar unos cuantos bits para cambiar el stream de salida sin que pueda ser detectado.

Basado en lo anterior, EAP-TLS constituye una alternativa de autenticación muy superior a PPTP, sin embargo, la implementación de EAP-TLS requiere la implementación de una infraestructura de clave pública (public-key infrastructure) para los certificados de cliente y servidor, lo cual podría ser un obstáculo para algunas instalaciones remotas. PPTP encapsula PPP en líneas virtuales que corren sobre IP. PPTP incorpora PPP y MPPE (Microsoft Point to Point Encryption) para crear enlaces encriptados. El propósito de este protocolo es crear conexiones seguras entre routers y también entre routers y clientes PPTP. Los clientes PPTP están disponibles en casi todos los sistemas operativos, incluso en Windows. RouterOS soporta Multilink PPP (también conocido como MP, MLPPP, MPPP, MLP, o Multilink) con lo cual se provee un método para esparcir el tráfico a través de múltiples conexiones PPP distintas. En una simple línea PPP los frames no pueden arribar fuera de orden, pero esto se puede solucionar si los frames se los divide entre múltiples conexiones PPP. Por este motivo el MP debe numerar los fragmentos para que puedan ser reordenados cuando lleguen al destino. MP es un ejemplo de tecnología de agregación de enlace. MP (Multilink PPP) provee MRRU y capacidad de Bridging a través de enlaces PPP.

• MRRU consiste en la habilidad de transmitir paquetes de tamaño 1500 y de mayor tamaño. o MRRU = Maximum Received Reconstructed Unit o El MRRU es similar al MTU (Maximum Transmission Unit), pero solo se aplica a los paquetes Multilink. o El MRRU es el máximo tamaño de paquete que una interface Multilink puede procesar. o Por default el MRRU es 1500 bytes, pero se puede configurar un diferente de MRRU si el equipo con el

que va a conversar permite/acepta ese nuevo valor. • La capacidad de hacer Bridging se obtiene del uso de BCP (Bridge Control Protocol) que es el que permite enviar

frames Ethernet a través de enlaces PPP. De esta forma es posible configurar un Bridge (usando PPTP) en lugar de utilizar EoIP. Para esto se necesita que el Bridge tenga una dirección MAC o una interface tipo Ethernet, ya que los enlaces PPP no tienen direcciones MAC. PPTP incluye contabilización (accounting) y autenticación (authentication) PPP para cada conexión PPTP. La autenticación y contabilización de cada conexión puede ser hecha a través de un cliente RADIUS o de forma local RouterOS soporta los tipos de encriptación

• MPPE 40bit RC4


Academy Xper t s 21

• MPPE 128bit RC4 El tráfico PPTP utiliza

• TCP puerto 1723 • IP protocol GRE

o GRE = Generic Routing Encapsulation o GRE = IP protocol ID 47

PPTP puede ser usado con la mayoría de firewalls y routers habilitando TCP 1723 y GRE (protocolo 47). De esta manera el tráfico puede ser ruteado a través del firewall o router. Las conexiones PPTP pueden resultar muy limitadas o incluso a veces hasta imposibles cuando se configura a través de una conexión enmascarada (NATeada). PPTP es un protocolo de túnel que utiliza la información y direccionamiento del enrutamiento IP, para ligar a los clientes a los servidores PPTP.

• La definición del servidor PPTP es casi lo mismo que para PPPoE, excepto que ninguna interface tiene que ser especificada.

• El cliente se define casi de la misma manera como un cliente PPPoE, excepto que una dirección IP tiene que ser especificada para el servidor.

Consejo: Se debe desbloquear el puerto 1723 en el firewall del router (el servidor PPTP) para que pueda llegar con su túnel. Es un túnel seguro para el transporte de trafico IP mediante PPP. La encapsulación de PPTP en líneas virtuales que corren sobre IP. PPTP incorpora PPP y MPPE (Microsoft Point-to-Point Encryption) para hacer enlaces cifrados. El objetivo de este protocolo es hacer conexiones seguras bien administradas entre los routers, así como entre los router clientes PPTP. Clientes están disponibles para y/o incluido en casi todos los sistemas operativos incluyendo Windows). Se crea una interface para cada túnel establecido con el servidor dado. Hay dos tipos de interfaces en la configuración de PPTP.

• Las interfaces estáticas se añaden administrativamente si hay una necesidad de hacer referencia al nombre de la interface en particular (en las reglas de firewall) creados por el usuario en particular.

• Las interfaces dinámicas se añaden a esta lista de forma automática cada vez que se conecta un usuario y su nombre de usuario no coincide con ninguna entrada estática existente.

Aparecen interfaces dinámicas cuando un usuario se conecta, y las mismas desaparecen una vez que el usuario se desconecta, por lo que es imposible hacer referencia al túnel creado con ese fin en la configuración del router (por ejemplo, en el servidor de seguridad), así que si necesitas reglas persistentes para ese usuario, crear una entrada estática para el usuario, de lo contrario es seguro usar configuración dinámica. El siguiente ejemplo muestra como conectar un ordenar a un red de oficina remota a través de una túnel PPTP encriptado, dando ese equipo una dirección IP de la misma red que la oficina remota tiene (sin necesidad de tender un bridge sobre túneles EoIP)

El router de la oficina está conectado a internet a través de ether1. Las estaciones de trabajo están conectados a ether2. Las portátiles están conectadas a internet, y puede alcanzar IP publica del router de la oficina (en nuestro ejemplo es 192.168.80.1) Primer paso es crear un usuario

/ppp secret add name=Laptop service=pptp password=123 local-address=10.1.101.1\ remote-address=10.1.101.100

/ppp secret print detail Flags: X – disabled 0 name=”Laptop” service=pptp caller-id=” ” password=”123” profile=default

local-address=10.1.101.1 remote-address=10.1.101.100 routes==” “


Academy Xper t s 22

Observe que la dirección local PPTP es la misma que la dirección del router en la interface local y la dirección remota es del mismo rango que la red local (10.1.101.0/24). El siguiente paso es habilitar el servidor PPTP y el cliente PPTP en la computadora portátil.

/interface pptp-server server set enabled=yes /interface pptp-server server print Enabled: yes max-mtu: 1460 max-mru: 1460 mrru: disabled authentication: mschap2 keepalive-timeout: 30 default-profiles: default

El cliente PPTP de la computadora portátil debe conectarse a routers IP publica que en nuestro ejemplo es 192.168.80.1 (consulte el manual respectivo sobre como configurar un cliente PPTP con el software del sistema operativo que esté utilizando). En este punto (cuando el cliente PPTP está conectado con éxito) si intenta hacer ping a cualquier estación de trabajo que forma parte de la red del ordenador portátil, el ping será el tiempo de espera debido a que el ordenador portátil está en condiciones de obtener aplicaciones de estaciones de trabajo. La solución es la creación de proxy arp en la interface local.

/interface ethernet set Office arp=proxy-arp /interface ethernet print Flags: X – disabled, R – running # Name MTU MAC-ADDRESS ARP 0 R ether1 1500 00:30:4F:0B:7B:C1 enabled 1 R ether2 1500 00:30:4F:06:62:12 proxy-arp

Luego que el proxy-arp este activado, el cliente remoto puede alcanzar con éxito todas las estaciones de trabajo en la red local detrás del router. PPTP Client (cliente pptp)

• add-default-route (yes | no; Default: no) .- Especifica si es que se agrega una dirección remota PPTP como

una ruta por default • allow (mschap2 | mschap1 | chap | pap; Default: mschap2, mschap1, chap, pap) .- Especifica los métodos de

autenticación permitidos • connect-to (IP; Default: ) .- Dirección remota del servidor PPTP • default-route-distance (byte [0..255]; Default: 1) .- Configura el valor de distancia aplicado para la ruta por

default creada automáticamete, si es que también se ha seleccionado add-default-route • dial-on-demand (yes | no; Default: no) .- Se conecta al servidor PPTP únicamente cuando se genera tráfico de

salida. Si esta opción está seleccionada, entonces la ruta con la dirección del gateway desde la red 10.112.112.0/24 será agregada mientras la conexión no está establecida

• disabled (yes | no; Default: yes) .- Especifica si la interface está deshabilitada o no. Por default está deshabilitada. • keepalive-timeout (integer; Default: 60) .- Configura el keepalive timeout en segundos • max-mru (integer; Default: 1460) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). Tamaño

máximo del paquete que la interface PPTP estará habilitada para recibir sin fragmentación de paquetes • max-mtu (integer; Default: 1460) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit). Tamaño

máximo del paquete que la interface PPTP estará habilitada para enviar sin fragmentación de paquetes • mrru (disabled | integer; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el enlace. Si

un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel

• name (string; Default: ) .- Nombre descriptivo de la interface • password (string; Default: "") .- Contraseña (password) usado para la autenticación


Academy Xper t s 23

• profile (name; Default: default-encryption) .- Especifica el perfil PPP que se usa • user (string; Default: ) .- Nombre de usuario (user name) usado para la autenticación

PPTP Server (servidor pptp) Se crea una interface por cada túnel establecido al servidor. Existen dos tipos de interfaces en la configuración PPTP Server

• Las interfaces estáticas son administrativamente agregadas si es que existe una necesidad para referenciar el nombre de interface en particular (por ejemplo en las reglas de firewall o en algún otro lugar) creada para un usuario en particular.

• Las interfaces dinámicas son agregadas a esta lista automáticamente si es que un usuario está conectado y su nombre de usuario (username) no coincide con cualquier entrada estática existente (o en caso de que la entrada ya está activa, ya que no puede haber dos interfaces de túnel separadas referenciadas por el mismo nombre)

Las interfaces dinámicas aparecen cuando un usuario se conecta y desaparece una vez que el usuario se desconecta, por lo que es imposible hacer referencia al túnel creado con ese fin en la configuración del router (por ejemplo, en firewall), así que si se necesitan reglas persistentes para ese usuario, se debe crear una entrada estática para ese usuario. De lo contrario es seguro usar la configuración dinámica.

Nota Importante En ambos casos los usuarios PPP deben ser configurados apropiadamente, las entradas estáticas no reemplazan la configuración PPP Parámetros

• authentication (pap | chap | mschap1 | mschap2; Default: mschap1,mschap2) .- Especifica los métodos de autenticación que el servidor aceptará

• default-profile (name; Default: default-encryption) .- Perfil PPP por default que se usará • enabled (yes | no; Default: no) .- Define si es que el servidor PPTP está habilitado o no • keepalive-timeout (time; Default: 30) .- Si el servidor durante el período keepalive no recibe ningún paquete,

se enviará paquetes keepalive cada segundo por cinco veces. Si el server no recibe respuesta del cliente, entonces se desconecta después de 5 segundos. La bitácora de eventos (LOG) mostrará 5 veces los mensajes “LCP missed echo reply” y luego se desconectará.

• max-mru (integer; Default: 1460) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). Tamaño máximo del paquete que la interface PPTP estará habilitada para recibir sin fragmentación de paquetes

• max-mtu (integer; Default: 1460) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit). Tamaño máximo del paquete que la interface PPTP estará habilitada para enviar sin fragmentación de paquetes

• mrru (disabled | integer; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el enlace. Si un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel

En Resumen Cómo trabaja PPTP

• PPTP está basado en autenticación, encriptación y negociación PPP • Este protocolo encripta los datos y los pone dentro de paquetes creando un túnel que provee una comunicación

segura sobre una LAN o WAN • Debido a que se debe encapsular los datos, y a que se debe encriptar y autenticar los mismos, PPTP es

relativamente seguro transmitir los datos sobre redes públicas, como internet. Sin embargo, su uso es más obsoleto cada día por los problemas de vulnerabilidad que se han encontrado.

• PPTP tiene 2 diferentes tipos de métodos de tunneling, que se usan de forma diferente: o Tunneling Voluntario (Voluntary Tunneling) cuando es iniciado por el Cliente. Este método no requiere

dispositivos de red como por ejemplo bridges o routers, ni tampoco soporte del ISP. o Tunneling Obligatorio (Compulsory Tunneling) cuando es iniciado por el Server. Este método debe ser

soportado por los routers y es iniciado por el servidor.


Academy Xper t s 24

Detalles técnicos de PPTP • PPTP soporta encriptación de clave de sesión de hasta 128-bit. Esta encriptación es realizada por el Protocolo de

Encriptación Punto a Punto que fue desarrollado por Microsoft • PPTP únicamente necesita nombre de usuario (user name), contraseña (password) y la dirección del servidor para

establecer una conexión confiable con el servidor. • PPTP soporta Windows (XP, 7, 8, 10), Linux, Tomato, Android y otros más. En las últimas versiones de MacOS ya

no se soporta PPTP. • PPTP utiliza el puerto TCP 1723 y GRE para la configuración de puerto

Ventajas de PPTP • PPTP soporta una gran variedad de sistemas operativos móviles y de escritorio, lo cual constituye una gran ventaja • PPTP es fácil de configurar y prácticamente cualquier persona, con poco conocimiento técnico o experiencia previa,

puede configurarlo • Debido al bajo nivel de encriptación, PPTP es uno de los protocolos VPN más rápidos, por lo que ha sido uno de

los más populares Desventajas de PPTP

• PPTP es un protocolo con varias décadas de antigüedad, y no es tan seguro como los protocolos más actuales • PPTP no es una buena elección para seguridad en línea (on-line), ni tampoco para mantener el anonimato en línea. • Existen pruebas de que agencias gubernamentales y autoridades especializadas como la NSA ya han craqueado

este protocolo.

RouterOS v6.40.3.01 – MAE-VPN-PPP, Túneles PPP con MikroTik RouterOS, Capítulo 3: L2TP

Academy Xper t s 25

Capítulo 3: L2TP L2TP es un protocolo de túnel seguro para transportar tráfico IP usando PPP. L2TP encapsula PPP en líneas virtuales que corren sobre IP, frame Relay y otros protocolos (que no son soportados actualmente por MikroTik RouterOS) L2TP incorpora PPP y MPPE (Microsoft Point to Point Encryption) para crear enlaces encriptados. El propósito de este protocolo es permitir que los extremos PPP y Capa 2 residan en diferentes dispositivos interconectados por una red conmutada de paquetes (packet-switched network) Con L2TP, un usuario tiene una conexión en Capa 2 a un concentrador de acceso – LAC (ejemplo: manco de módems, ADSL DSLAM, etc.), y el concentrador entonces hace túneles de frames PPP individuales al Servidor de Acceso de Red (NAS = Network Access Server). Esto permite que el procesamiento real de paquetes PPP sea separado de la terminación del circuito de Capa 2. Desde la perspectiva del usuario, no existe diferencia funcional entre tener que el circuito en Capa 2 termine en un NAS directamente o usando L2TP. Puede ser útil usar L2TP únicamente como cualquier otro protocolo de túnel con o sin encriptación. El estándar L2TP establece que la forma más segura de encriptar datos es usar L2TP sobre IPsec (este es el modo por default para cliente Microsoft L2TP) ya que todos los paquetes de control y datos de L2TP de un túnel aparecen como paquetes de datos UDP/IP homogéneos para el sistema IPsec. Se soporta Multilink PPP (MP) para poder proveer MRRU (la habilidad para transmitir paquetes de 1500 y más grandes) y Bridging sobre enlaces PPP (usando BCP=Bridge Control Protocol, el cual permite enviar frames Ethernet sobre enlaces PPP). De esta forma es posible configurar Bridging sin EoIP. El bridge debería tener ya sea una dirección MAC administrativa o una interface tipo Ethernet, ya que los enlaces PPP no tienen direcciones MAC. L2TP incluye autenticación (authentication) y contabilización (accounting) PPP para cada conexión L2TP. Una completa autenticación y contabilización de cada conexión puede ser realizada a través de un cliente RADIUS o localmente. Métodos de encriptación soportados

• MPPE 40bit RC4 • MPPE 128bit RC4

El protocolo L2TP utiliza el protocolo UDP para los paquetes de control y de datos. El puerto UDP 1701 se utiliza únicamente para establecer el enlace, el tráfico adicional puede utilizar cualquier puerto UDP (que puede o no ser el 1701). Esto significa que L2TP puede ser usado con la mayoría de firewalls y routers (incluso con NAT) tan solo habilitando que el tráfico UDP sea ruteado a través del firewall o del router. L2TP Client (cliente l2tp)

• add-default-route (yes | no; Default: no) .- Especifica si es que se agrega una dirección remota L2TP como

una ruta por default • allow (mschap2 | mschap1 | chap | pap; Default: mschap2, mschap1, chap, pap) .- Especifica los métodos de

autenticación permitidos • connect-to (IP; Default: ) .- Dirección remota del servidor L2TP • coment (string; Default: ) .- Breve descripción del túnel • default-route-distance (byte; Default:) .- Desde la v6.2 se configura el valor de distancia aplicado para la

ruta por default creada automáticamete, si es que también se ha seleccionado add-default-route • dial-on-demand (yes | no; Default: no) .- Se conecta únicamente cuando se genera tráfico de salida. Si esta

opción está seleccionada, entonces la ruta con la dirección del gateway desde la red 10.112.112.0/24 será agregada mientras la conexión no está establecida


Academy Xper t s 26

• disabled (yes | no; Default: yes) .- Especifica si la interface está deshabilitada o no. Por default está deshabilitada. • keepalive-timeout (integer [1..4294967295]; Default: 60s) .- Desde la v6.0rc13, el keepalive timeout se

representa en segundos • max-mru (integer; Default: 1460) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). Tamaño

máximo del paquete que la interface L2TP estará habilitada para recibir sin fragmentación de paquetes • max-mtu (integer; Default: 1460) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit). Tamaño

máximo del paquete que la interface L2TP estará habilitada para enviar sin fragmentación de paquetes • mrru (disabled | integer; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el enlace. Si

un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel

• name (string; Default: ) .- Nombre descriptivo de la interface • password (string; Default: "") .- Contraseña (password) usado para la autenticación • profile (name; Default: default-encryption) .- Especifica el perfil PPP que se usa • user (string; Default: ) .- Nombre de usuario (user name) usado para la autenticación

L2TP Server (servidor l2tp) Se crea una interface por cada túnel establecido al servidor. Existen dos tipos de interfaces en la configuración L2TP Server

• Las interfaces estáticas son agregadas administrativamente si es que existe una necesidad para referenciar el nombre de interface en particular (por ejemplo en las reglas de firewall o en algún otro lugar) creada para un usuario en particular.

• Las interfaces dinámicas son agregadas a esta lista automáticamente si es que un usuario está conectado y su nombre de usuario (username) no coincide con cualquier entrada estática existente (o en caso de que la entrada ya está activa, ya que no puede haber dos interfaces de túnel separadas referenciadas por el mismo nombre)

Las interfaces dinámicas aparecen cuando un usuario se conecta y desaparece una vez que el usuario se desconecta, por lo que es imposible hacer referencia al túnel creado con ese fin en la configuración del router (por ejemplo, en firewall), así que si se necesitan reglas persistentes para ese usuario, se debe crear una entrada estática para ese usuario. De lo contrario es seguro usar la configuración dinámica.

Nota Importante En ambos casos los usuarios PPP deben ser configurados apropiadamente, las entradas estáticas no reemplazan la configuración PPP Parámetros

• authentication (pap | chap | mschap1 | mschap2; Default: mschap1,mschap2) .- Especifica los métodos de autenticación que el servidor aceptará

• default-profile (name; Default: default-encryption) .- Perfil PPP por default que se usará • enabled (yes | no; Default: no) .- Define si es que el servidor L2TP está habilitado o no • keepalive-timeout (time; Default: 30) .- Si el servidor durante el período keepalive-timeout no recibe

ningún paquete, se enviará paquetes keepalive cada segundo, por cinco veces. Si el server no recibe respuesta del cliente, entonces se desconecta después de 5 segundos. La bitácora de eventos (LOG) mostrará 5 veces los mensajes “LCP missed echo reply” y luego se desconectará. Este parámetro está disponible a partir de las versiones v5.22 y v6rc3

• max-mru (integer; Default: 1460) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). Tamaño máximo del paquete que la interface L2TP estará habilitada para recibir sin fragmentación de paquetes

• max-mtu (integer; Default: 1460) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit). Tamaño máximo del paquete que la interface L2TP estará habilitada para enviar sin fragmentación de paquetes


Academy Xper t s 27

• mrru (disabled | integer; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el enlace. Si un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel

En Resumen Cómo trabaja L2TP

• L2TP mejora el PPP ya que PPP hace que los paquetes de datos sean vulnerables durante la transmisión entre clientes y servidores

• Los datos transmitidos vía L2TP incluyen la cabecera L2TP con cada paquete, y al recibir estos paquetes se demultiplexan. Debido a este trabajo extra, el desempeño de L2TP disminuye, pero a cambio entrega una transmisión altamente segura.

• L2TP combina las características de L2F y PPTP dando como resultado una alta seguridad, a costa de una velocidad reducida.

Detalles técnicos de L2TP • Utiliza claves (keys) de encriptación AES-256 bit, o algoritmo de encriptación 3DES • La carga útil (payload) de L2TP es encriptada por IPSec • L2TP se considera seguro y no se conocen vulnerabilidades • L2TP tiene un overhead más alto comparado con otros estándares debido a la doble encriptación • Todos los sistemas operativos Windows y Mac OS soportan L2TP de forma nativa. También soporta plataformas

Linux, iOS y Android • L2TP utiliza los puertos

o UDP 500 para el intercambio inicial de clave (initial key Exchange) o UDP 1701 para configuración o UDO 4500 para NAT

Ventajas de L2TP • L2TP soporta una gran variedad de sistemas operativos móviles y de escritorio, lo cual constituye una gran ventaja • Debido al soporte nativo es fácil de configurar y cualquier persona con poco o ningún conocimiento técnico o

experiencia previa puede configurarlo • Utiliza estándares de encriptación poderosos y avanzados, con lo que se asegura la integridad de los datos

permanece intacta Desventajas de L2TP

• Existen rumores de que L2TP ha sido violentado por autoridades gubernamentales, logrando tener acceso al tráfico transmitido utilizando L2TP

• L2TP es ligeramente más lento que otros protocolos debido a la doble encapsulación • L2TP es más complicado que OpenVPN y presenta más dificultad de configurar en dispositivos que utilizan routers

NAT

RouterOS v6.40.3.01 – MAE-VPN-PPP, Túneles PPP con MikroTik RouterOS, Capítulo 4: PPPoE

Academy Xper t s 28

Capítulo 4: PPPoE El protocolo PPPoE (Point to Point Protocolo ver Ethernet) proporciona una amplia administración de usuario, administración de red y beneficios de contabilización (accounting) a los ISPs y administradores de red. En muchos sitios el PPPoE se utiliza principalmente en los ISPs para controlar las conexiones de clientes por xDSL y Cable Modem, así como también por redes Ethernet planas (plain networks). PPPoE es una extensión del estándar PPP. La diferencia entre ambos está en el medio de transporte, ya que PPPoE utiliza Ethernet en lugar de conexiones de modem serial. Generalmente PPPoE se utiliza para manejar las direcciones IP a clientes basados en autenticación por nombre de usuario (incluso si se requiere también por estación de trabajo) en lugar de la autenticación únicamente por estación de trabajo donde se utiliza direccionamiento estático o DHCP. Se recomienda no utilizar direccionamiento estático o DHCP en las mismas interfaces como PPPoE por razones de seguridad. El cliente y server PPPoE trabajan sobre:

• Cualquier interface Ethernet Capa 2 • Wireless 802.11 (Aironet, Cisco, WaveLan, Prism, Atheros) • Ethernet 10/100/1000 Mbit/s • RadioLan • EoIP (túnel Ethernet sobre IP)

Características principales de PPPoE • Soporte para cliente y server PPPoE • Multilink PPP (MLPPP) • MLPPP sobre un enlace simple (habilidad para transmitir frames de tamaño completo) • Soporte para BCP (Bridge Control Protocol). Permite el envío de frames Ethernet sobre enlaces PPP • Encriptación MPPE 40bits • Encriptación MPPE 128 RSA • Autenticación pap, chap, mschap v1, mschap v2 • Soporte RADIUS para autenticación y contabilización de clientes

Nótese que cuando el servidor RADIUS está autenticando un usuario con CHAP, MS-CAHPv1 o MS-CHAPv2, el protocolo RADIUS no usa una clave compartida (shared secret), ya que esta calve compartida se utiliza únicamente en la respuesta a la autenticación. Esto significa que, si se tiene una clave compartida errónea, el servidor RADIUS aceptará el requerimiento. Se puede entonces utilizar el comando /radius monitor para visualizar el parámetro bad-replies. Este valor debería incrementar cada vez que un cliente intenta conectarse. Conexiones soportadas

• El Cliente PPPoE MikroTik RouterOS se puede conectar con cualquier servidor PPPoE (concentrador de acceso) • El Servidor PPPoE MikroTik RouterOS (concentrador de acceso) se puede conectar con múltiples clientes PPPoE

(los clientes pueden provenir de casi todos los sistemas operativos y la mayoría de routers) Operación PPPoE Estados PPPoE tiene 2 estados

1) Descubrimiento (Discovery) .- Un cliente descubre todos los concentradores de acceso disponible, y selecciona uno de ellos para establecer la sesión PPPoE. Este estado tiene cuatro pasos:

a. Inicialización (initialization) b. Oferta (offer) c. Request (requerimiento) d. Confirmación de sesión (sesión confirmation)

• PPPoE Discovery utiliza frames Ethernet especiales con su propio tipo de frame Ethernet (0x8863) • Para iniciar el descubrimiento, el cliente PPPoE envía un frame PADI a la dirección Ethernet broadcast

FF:FF:FF:FF:FF:FF, y opcionalmente puede especificar un nombre de servicio (service name) • Cuando el server recibe el frame PADI, el server responde con un frame PADO a la dirección Ethernet

unicast del Cliente. Puede haber más de un servidor en el rango broadcast del cliente. En tal caso el Cliente colecciona los frames PADO y elige uno para iniciar la sesión. En la mayoría de los casos elige el servidor que responde primero.

• El Cliente envía un frame PADR a la dirección Ethernet unicast del Server que elige. Si el Server está de acuerdo en configurar una sesión con este Cliente, entonces asigna recursos para configurar una sesión PPP y asigna un número de Identificación de Sesión (Session ID). Este número se envía de retorno al Cliente en un frame PADS. Cuando el Cliente recibe el frame PADS, conoce la dirección MAC de los servidores y el Session ID, asigna los recursos y la sesión puede comenzar.


Academy Xper t s 29

2) Sesión (Session) .- Cuando se completa el estado Discovery, ambas partes conocen el PPPoE Session ID y la dirección MAC Ethernet de cada uno, con lo cual juntos definen la sesión PPPoE. Los frames PPPoE son encapsulados en frames de sesión PPPoE, los mismos que tienen un tipo de frame Ethernet 0x8864 Cuando el Server envía la confirmación y el Cliente la recibe, se inicia el estado de Sesión PPP que consiste de los siguientes pasos:

a. Negociación LCP b. Autenticación c. Negociación IPCP, donde se le asigna una dirección IP al Cliente

El Server PPPoE envía paquetes Echo-Request al Cliente para determinar el estado de la sesión, de otra forma el Server no podrá determinar que la sesión está terminada en los casos en que el Cliente termina la sesión sin enviar el paquete Terminate-Request

Tipos de paquetes utilizados PADI – PPPoE Active Discovery Initialization

El Cliente PPPoE envía un paquete PADI a la dirección broadcast. Este paquete también puede poblar el campo service-name si un nombre de servicio ha sido ingresado en las propiedades de networking dial-up del cliente PPPoE. Si no se ha ingresado un service-name, este campo nos será poblado

PADO – PPPoE Active Discovery Offer El Server PPPoE (Concentrador de Acceso) debe responder al PADI con un PADO si el Concentrador de Acceso está habilitado para servir el campo service-name que ha sido listada en el paquete PADI. Si ningún campo service-name ha sido listado, el Concentrador de Acceso responderá con un paquete PADO que tiene el campo service-name poblado con los nombres de servicio que el Concentrador de Acceso puede servir. El paquete PADO se envía a la dirección unicast del cliente PPPoE

PADR – PPPoE Active Discovery Request Cuando se recibe un paquete PADO, el Cliente PPPoE responde con un paquete PADR. Este paquete se envía a la dirección unicast del Concentrador de Acceso. El cliente puede recibir múltiples paquetes PADO, pero el cliente responde al primer PADO válido que el cliente recibió. Si el paquete inicial PADI tiene un campo service-name en blanco, el cliente puebla el campo service-name del paquete PADR con el nombre del primer servicio que retorna en el paquete PADO.

PADS – PPPoE Active Discovery Session confirmation Cuando se recibe el PADR, el Concentrador de Acceso genera una identificación de sesión única (ID) para la sesión PPP y regresa este ID al Cliente PPPoE en el paquete PADS. Este paquete es enviado a la dirección unicast del Cliente.

PADT – PPPoE Active Discovery Terminate Puede ser enviado en cualquier momento después de que se establece una sesión para indicar una sesión PPPoE terminada. Puede ser enviada por el Server como por el Cliente.

MTU Típicamente el frame Ethernet más grande que se puede transmitir sin fragmentación es 1500 bytes. El protocolo PPPoE agrega 6 bytes de overhead y el campo PPP agrega 2 bytes más, dejando 1492 bytes para el datagrama IP. Por lo tanto, los valores máximos de MTU y MRU para PPPoE no deben ser mayores a 1492. Las pilas TCP tratan de evitar la fragmentación, por lo que usan un MSS (Maximum Segment Size). Por default el MSS es elegido como el MTU de la interface saliente menos el tamaño usual de las cabeceras IP y TCP (40 bytes), lo cual resulta en 1460 bytes para una interface Ethernet. Desafortunadamente puede haber enlaces intermedios con un MTU más bajo el cual puede ocasionar fragmentación. En tal caso, la pila TCP ejecuta un path MTU discovery. Los routers que no pueden


Academy Xper t s 30

pasar el datagrama sin fragmentación se supone que abandonarán/rechazarán (drop) el paquete y enviarán un mensaje ICMP-Fragmentation-Required al host origen. Cuando el host recibe este paquete ICMP, intenta disminuir el MTU. Esto debería funcionar en un esquema ideal, sin embargo, en el mundo real muchos routers no generan los datagramas fragmentation-requiered, y también muchos firewalls abandonan/rechazan (drop) todos los datagramas ICMP. La solución para este problema es ajustar el MSS si es que es demasiado grande. Por default el RouterOS agrega reglas de mangle para interceptar los paquetes TCP SYN y silenciosamente ajusta cualquier opción MSS anunciando la que será apropiada para el enlace PPPoE. pppoe client (Cliente PPPoE)

Propiedades

• ac-name (string; Default: "") .- Nombre del Concentrador de Acceso. Este campo puede ser dejado en blanco y el cliente se conectará a cualquier Concentrador de Acceso en el dominio de broadcast.

• add-default-route (yes|no; Default: no) .- Habilita/Deshabilita si es que se agregará automáticamente la ruta por default.

• allow (mschap2 | mschap1 | chap | pap; Default: mschap2, mschap1, chap, pap) .- Especifica los métodos de autenticación permitidos. Por default todos los métodos están permitidos.

• default-route-distance (byte [0..255]; Default: 1) .- Configura el valor de distancia aplicado para la ruta por default creada automáticamete, si es que también se ha seleccionado add-default-route

• dial-on-demand (yes | no; Default: no) .- Se conecta al Concentrador de Acceso únicamente cuando se genera tráfico de salida. Si esta opción está seleccionada, entonces la ruta con la dirección del gateway desde la red 10.112.112.0/24 será agregada mientras la conexión no está establecida

• interface (string; Default: ) .- Nombre de la interface en la cual correrá el cliente • keepalive-timeout (integer; Default: 60) .- Configura el keepalive timeout en segundos • max-mru (integer; Default: 1460) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). • max-mtu (integer; Default: 1460) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit • mrru (disabled | integer 512..65535; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el

enlace. Si un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel

• name (string; Default: ) .- Nombre de la interface PPPoE. Se genera automáticamente por el RouterOS si es que no se especifica.

• password (string; Default: "") .- Contraseña (password) usado para la autenticación • profile (name; Default: default-encryption) .- Especifica el perfil por default para la conexión definida en /ppp

profiles • service-name (string; Default: "") .- Especifica el nombre de servicio configurado en el Concentrador de Acceso.

Puede ser dejado en blanco para conectarse a cualquier Server PPPoE • use-peer-dns (yes|no; Default: no) .- Habilita/Deshabilita la obtención de las configuraciones DNS desde su peer • user (string; Default: ) .- Nombre de usuario (user name) usado para la autenticación

PPPoE service-name • El service-name puede ser visto como el SSID de 802.11, lo que significa que es el nombre de red que el cliente

este buscando. • A diferencia del SSID, si el cliente no especifica uno, el concentrador de acceso (servidor PPPoE) enviara todos los

service-names que administre. El cliente responderá al primero que llegue. Status El comando /interface pppoe-client monitor mostrará el estatus PPPoE actual Propiedades


Academy Xper t s 31

• ac-mac (MAC address) .- La dirección MAC del Concentrador de Acceso al que el Cliente está conectado • ac-name (string) .- Nombre del Concentrador de Acceso • active-links (integer) .- Número de las conexiones MLPPP unidas (‘1’ si no se está usando MLPPP) • encoding (string) .- Encriptación y codificación (si es asimétrico, separado con ‘/’) que está siendo usado en esta

conexión. • local-address (IP Address) .- Dirección IP asignada al cliente • remote-address (IP Address) .- Dirección IP remota asignada al Server (por ejemplo la dirección del Gateway) • mru (integer) .- MRU efectivo del enlace • mtu (integer) .- MTU efectivo del enlace • service-name (string) .- Nombre del servicio utilizado • status (string) .- Estatus actual del enlace. Los valores disponibles son:

• dialing (marcando) • verifying password... (verificando contraseña) • connected (conectado) • disconnected (desconectado)

• uptime (time) .- Tiempo de conexión mostrado en días, horas, minutos y segundos.

Scanner A partir de la v3.21 RouterOS agregó la herramienta PPPoE Scanner. Esta herramienta permite escanear todos los servidores PPPoE activos en el dominio de broadcast. /interface pppoe-client scan <interface>

Propiedades


Academy Xper t s 32

• service (string) .- Nombre del servicio configurado en el Server • mac-address (MAC) .- Dirección MAC del Server detectado • ac-name (string) .- Nombre del Concentrador de Acceso

Notas importantes En Windows, algunas instrucciones de conexión pueden usar la forma donde el phone number, por ejemplo, MikroTik_AC\mt1, se especifica para indicar que MikroTik_AC es el nombre del Concentrador de Acceso (AC), y mt1 es el nombre del servicio. La especificación del MRRU significa que se habilita MP (Multilink PPP) sobre un enlace simple. Este protocolo se utiliza para dividir los paquetes grandes en paquetes más pequeños. En Windows esto se puede habilitar en la pestaña Networking, botón Configuración, opción “Negociar multi-link para conexiones de enlace simple”. El MRRU en Windows está codificado en 1614. Esta configuración es útil para resolver fallas de PathMTU Discovery. La configuración MP debe estar habilitada en ambas partes. Configuración del Server PPPoE (Concentrador de Acceso) /interface pppoe-server server

El Server PPPoE (Concentrador de Acceso) soporta múltiples servers para cada interface, con diferentes nombres de servicio (service-name). El Throughput del Server PPPoE ha sido probado a 160 Mbps en un CPU Celeron 600. El uso de CPUs de mayor velocidad debería incrementar proporcionalmente el Throughput. El nombre del Concentrador de Acceso y el nombre del servicio PPPoE son usados por los clientes para identificar el concentrador de acceso al cual se quieren registrar. El nombre del concentrador de acceso es el mismo que la identidad del router que se muestra antes del command prompt. La identidad se puede configurar en /system identity Es importante recordar que, si no se especifica un nombre de servicio en Windows XP, únicamente usará un servicio sin nombre. Por lo tanto, si se desea atender clientes Windows XP, se debe dejar el nombre de servicio vacío. Propiedades

• authentication (mschap2 | mschap1 | chap | pap; Default: "mschap2, mschap1, chap, pap") .- Algoritmo de autenticación.

• default-profile (string; Default: "default") .- Perfil de usuario por default que se va a utilizar • interface (string; Default: "") .- Interface a la que los clientes se conectan • keepalive-timeout (time; Default: "10") .- Define el período de tiempo (en segundos) después del cual el router

inicia el envío de paquetes keepalive cada segundo. Si es que no existe tráfico y no arriban respuestas keepalive en ese período de tiempo (por ejemplo, 2*keepalive-timeout), el cliente que no responde se proclama como desconectado.

• max-mru (integer; Default: "1480") .- Maximum Receive Unit. El valor óptimo es el MTU de la interface en la que el túnel está trabajando, disminuido en 20. Por ejemplo, para un enlace Ethernet de 1500-bytes, se debe configurar el MTU en 1480 para evitar la fragmentación de paquetes.

• max-mtu (integer; Default: "1480") .- Maximum Transmission Unit. El valor óptimo es el MTU de la interface en la que el túnel está trabajando, disminuido en 20. Por ejemplo, para un enlace Ethernet de 1500-bytes, se debe configurar el MTU en 1480 para evitar la fragmentación de paquetes.

• max-sessions (integer; Default: "0") .- Número máximo de clientes que el Concentrador de Acceso puede atender. 0 (cero) significa que no hay limitantes.


Academy Xper t s 33

• mrru (integer: 512..65535 | disabled; Default: "disabled") .- Tamaño máximo del paquete que puede ser recibido en el enlace. Si un paquete es más grande que el túnel MTU, será divido en múltiples paquetes, permitiendo el tamaño completo de los paquetes IP o Ethernet que serán enviados a través del túnel.

• one-session-per-host (yes | no; Default: "no") .- Se permite únicamente una sesión por host (determinado por la dirección MAC). Si un host intenta establecer una nueva sesión, la anterior será cerrada.

• service-name (string; Default: "") .- El nombre de servicio PPPoE. El servidor aceptará clientes a los cuales envía el mensaje PADI con service-names que concuerden con esta configuración o si el campo de service-name en el mensaje PADI no está configurado.

Notas importantes El valor por default de 10 segundos del parámetro keepalive-timeout es adecuado en la mayoría de los casos. Si se configura este parámetro como 0 (cero), el router no desconectará a los clientes hasta que ellos explícitamente hagan log-out o hasta que el router reinicie. Para resolver este problema, se puede utilizar la propiedad one-session-per-host. Como punto importante de seguridad recuerde que no debe asignar una dirección IP a la interface en la cual se recibirán los requerimientos PPPoE. La especificación del MRRU significa que se habilita MP (Multilink PPP) sobre un enlace simple. Este protocolo se utiliza para dividir los paquetes grandes en paquetes más pequeños. En Windows esto se puede habilitar en la pestaña Networking, botón Configuración, opción “Negociar multi-link para conexiones de enlace simple”. El MRRU en Windows está codificado en 1614. Esta configuración es útil para resolver fallas de PathMTU Discovery. La configuración MP debe estar habilitada en ambas partes. PPPoE Server (Servidor PPPoE) /interface pppoe-server

Una interface se crea por cada túnel establecido al servidor dado. Las interfaces estáticas se agregan administrativamente si es que existe la necesidad de referenciar el nombre de la interface en particular (en reglas en firewall u otro lugar) creada para el usuario en particular. Se crea una interface por cada túnel establecido al servidor. Existen dos tipos de interfaces en la configuración PPTP Server

• Las interfaces estáticas se agregan administrativamente si es que existe una necesidad para referenciar el nombre de interface en particular (por ejemplo en las reglas de firewall o en algún otro lugar) creada para un usuario en particular.

• Las interfaces dinámicas son agregadas a esta lista automáticamente si es que un usuario está conectado y su nombre de usuario (username) no coincide con cualquier entrada estática existente (o en caso de que la entrada ya está activa, ya que no puede haber dos interfaces de túnel separadas referenciadas por el mismo nombre. Si existe problema se debe configurar el valor one-session-per-host.

Las interfaces dinámicas aparecen cuando un usuario se conecta y desaparece una vez que el usuario se desconecta, por lo que es imposible hacer referencia al túnel creado con ese fin en la configuración del router (por ejemplo, en firewall), así que si se necesitan reglas persistentes para ese usuario, se debe crear una entrada estática para ese usuario. De lo contrario es seguro usar la configuración dinámica. Es importante notar que en ambos casos los usuarios PPP deben ser configurados apropiadamente. Las entradas estáticas no reemplazan la configuración PPP. Propiedades

• encoding (read-only: text) .- Encriptación y codificación (si es asimétrico, separado con ‘/’) que está siendo usado en esta conexión.

• mru (integer) .- MRU del cliente • mtu (integer) .- MTU del cliente • name (name) .- Nombre de la interface • remote-address (read only: MAC address) .- Dirección MAC del cliente conectado • service (string) .- Nombre del servicio al que el usuario está conectado • uptime (time) .- Tiempo que el cliente ha estado conectado • user (name) .- Nombre del usuario conectado (debe estar presente en la base de datos de usuario)

Creando un PPPoE server • Un PPPoE server es el dispositivo que ofrece el servicio de tunelización • Permite a los clientes obtener un servicio de VPN seguro a la capa 3 a través de la infraestructura de la capa 2. • Usted no puede llegar a un servidor PPPoE a través de routers. Ya que es un protocolo de capa 2, el servidor solo

se puede llegar a través del mismo dominio de difusión Ethernet a la que los clientes pertenecen. • Antes de crear el servidor, creamos los parámetros de configuración que usted requiere tales como:

o IP Pool o PPP profiles

• PPP secrets Crear la interface de servidor de la interface física frente a los clientes Ejemplo:

/ip pool add name=Pool-PC ranges=192.168.5.50-192.168.5.99, 192.168.5.150-192.168.5.199


Academy Xper t s 34

add name=Pool-VPN ranges=192.168.5.100-192.168.5.149 /ppp profile add change-tcp-mss=yes local-address=192.168.222.1 name=Profile-external \ remote-address=192.168.222.2 use-compression=yes use-encryption=yes \ use-vj-compression=no add change-tcp-mss=no dns-server=192.168.5.1 local-address=192.168.5.1\ name=Profile-internal remote-address=Pool-VPN use-compression=yes\ use-encryption=yes use-vj-compression=no

/ppp secret add name=Pod4-external password=pod4-123 profile=Profile-external routes=192.168.4.0/24 add name=alain password=alain!! profile=Profile-internal /interface pppoe-server server add authentication=mschap2 default-profile=Profile-external disabled=no \ interface=ether1 mrru=1600 service-name=PPPoE-external add authentication=mschap2 default-profile=Profile-internal disabled=no \ interface=ether5 mrru=1600 service-name=PPPoE-internal

Tip: Usted puede dejar un puerto Ethernet sin un puerto maestro, un bridge o una dirección IP y el cliente que está conectado a este puerto pueden conseguir todavía el acceso a Internet si el servidor PPPoE (y el cliente PPPoE) está configurado correctamente. Direcciones Point-to-Point

• Direcciones desde /ppp secret tienen prioridad sobre /ppp profile, y ellos tienen prioridad sobre /ip pool. • Tanto las direcciones locales y remotas pueden ser únicas o de un Pool • Direcciones estáticas o direcciones por medio de DHCP no se deben utilizar en interfaces de clientes PPPoE.

Creando Clientes PPPoE en un RouterOS • Si desea utilizar un perfil diferente que el de por defecto, crearlo primero. • Crear la interface de cliente en la interface de cara al ISP

Ejemplo /ppp profile add change-tcp-mss=yes name=Profile-external use-compression=yes \ use-encryption=yes use-vj-compression=no /interface pppoe-client add ac-name=" " add-default-route=yes allow=mschap2 default-route-distance=1\ dial-on-demand=no disabled=no interface=ether1 keepalive-timeout=60 max-mru=1480 max-mtu=1480 mrru=disabled name=Client-PPPoE password=pod4-123 profile=Profile-external service-name=" " use-peer-dns=no user=Pod4-external

Habilite la interface del cliente. Tip El router no tendría que ser configurado con un cliente DHCP en la interface WAN y esto aún funcionará si el servidor PPPoE está en la misma infraestructura de capa 2 como puerto WAN.

Tuneles PPP con MikroTik RouterOS v6.40.3.01

Documents

Transcript of Tuneles PPP con MikroTik RouterOS v6.40.3.01