[2024-feb-29] Sad news: Eric Layton aka Nocturnal Slacker aka vtel57 passed away on Feb 26th, shortly after hospitalization. He was one of our Wiki's most prominent admins. He will be missed.

Welcome to the Slackware Documentation Project

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anteriorRevisión previa
Próxima revisión
Revisión previa
Próxima revisiónAmbos lados, revisión siguiente
es:howtos:network_services:ethernet_bridging_with_openvpn [2019/02/14 06:52 (UTC)] – [Configuración de la máquina virtual en VirtualBox] rrampes:howtos:network_services:ethernet_bridging_with_openvpn [2019/02/16 21:09 (UTC)] – [Configuración de OpenVPN] rramp
Línea 90: Línea 90:
 ==== Configuración de la máquina virtual en VirtualBox ==== ==== Configuración de la máquina virtual en VirtualBox ====
  
-El servidor de puerta de enlace es otra máquina Slackware cuya configuración de memoria es la misma, ..+El servidor de puerta de enlace es otra máquina Slackware cuya configuración de memoria es la misma, disco duro y conjuntos de discos  como el 'Servidor privado' anteriorSe diferencia en que tiene un segundo NIC configurado en VirtualBox
-The server gateway is another Slackware machine setup with the same memory, hard disk and disk sets as the 'Private Server' above.  It differs, however in that it has a second NIC configured in VirtualBox.+<del>The server gateway is another Slackware machine setup with the same memory, hard disk and disk sets as the 'Private Server' above.  It differs, however in that it has a second NIC configured in VirtualBox. 
 +</del>
  
-The first NIC in VirtualBox aka 'Adapter 1' in the VirtualBox GUI will end up being eth0 in the booted Slackware virtual machine, just bear this in mind.  I will set this as 'Bridged Adapter' under 'Attached to:' in the GUI.   Note that for all NICs I'm setting 'Promiscuous Mode' to 'Allow All', although I've no idea if that's needed for all the NICs on all the machines in this guide.+El primer NIC en VirtualBox también conocido como 'adaptador 1' terminará siendo eth0 en la máquina virtual iniciada, tenga en cuenta esto.  
 +Estableceré esto como 'Adaptador puenteado' en 'Adjunto a:' en la GUI. Note que para todas las NICs yo estoy configurando 'modo promiscuo' a 'permitir todo', aunque no tengo idea si eso es necesario para todas las NICs en todas las máquinas de esta guía. 
 +<del>The first NIC in VirtualBox aka 'Adapter 1' in the VirtualBox GUI will end up being eth0 in the booted Slackware virtual machine, just bear this in mind.  I will set this as 'Bridged Adapter' under 'Attached to:' in the GUI.   Note that for all NICs I'm setting 'Promiscuous Mode' to 'Allow All', although I've no idea if that's needed for all the NICs on all the machines in this guide.</del>
  
-'Adapter 2' will be connected to the 'slacknet' private network discussed in the 'Private Serverconfiguration above.+El 'Adaptador 2' se conectará a la red privada 'slacknet' que se describe en la configuración de 'Servidor privadomás arriba.
  
-==== Network setup ====+<del> 
 +'Adapter 2' will be connected to the 'slacknet' private network discussed in the 'Private Server' configuration above.</del>
  
-Now all the questions Slackware asks you during network setup apply to the public interface which is connected directly (via VirtualBox's bridgeto the switch in the middle of the diagram aboveChances are it is your home broadband router which will dish out an IP address and maybe (if you're luckyan appropriate DNS name It matters notso long as there is something you can use to identify this public interface on the network From here on I'm going to refer to this machine'ethernet interface as 'vpn', or we can say 'vpn.localnet', however if you only have an IP address just use that.  The good news is that it doesn't matter if it 'clashes' with the IP address range we talked about in 'Private Server' dnsmasq configuration because... well... it's really private.  Neat huh?  This would obviously be a big issue if we want to later add routing from 'Private Server' to the outside world, but that will be another howto.+==== Configuración de red ==== 
 +Ahora todas las preguntas que Slackware le hace durante la configuración de la red se aplican a la interfaz pública que está conectada directamente (a través del puente de VirtualBox) al conmutador en el centro del diagrama anterior 
 +Lo más probable es que sea el enrutador de banda ancha de su hogar el que proporcionará una dirección IP y tal vez (si tiene suerteun servidor de nombres (DNS) apropiado. 
 +No importasiempre que haya algo que pueda usar para identificar está interfaz pública en la red. 
 +De aquí en adelante, me referiré a la interfaz ethernet de está maquina como 'vpn', o podemos decir 'vpn.localnet', aunque, si solo tiene una dirección IP, solo use esa.
  
-==== tap0 device ====+<del>Now all the questions Slackware asks you during network setup apply to the public interface which is connected directly (via VirtualBox's bridge) to the switch in the middle of the diagram above. Chances are it is your home broadband router which will dish out an IP address and maybe (if you're lucky) an appropriate DNS name.  It matters not, so long as there is something you can use to identify this public interface on the network.  From here on I'm going to refer to this machine's ethernet interface as 'vpn', or we can say 'vpn.localnet', however if you only have an IP address just use that. 
 +  The good news is that it doesn't matter if it 'clashes' with the IP address range we talked about in 'Private Server' dnsmasq configuration because... well... it's really private.   
 +  Neat huh?  This would obviously be a big issue if we want to later add routing from 'Private Server' to the outside world, but that will be another howto.
  
-Having installed a nice shiny 2nd Slackware virtual machine with two ethernet cardsonly one of which is active we need to do some extra stuff before we talk about OpenVPN.+</del> 
 +Las buenas noticias es que no importa si esta 'choca' con el rango de direcciones IP de las que hablamos en la configuración de dnsmasque de el 'servidor privado' por que... bueno... esto es realmente privado. 
 +Limpio eh? Obviamenteesto sería un gran problema si queremos agregar más adelante el enrutamiento del 'Servidor privado' al mundo exterior, pero ese será otro ejemplo.
  
-The first step is to install [[https://slackbuilds.org/repository/14.2/network/tunctl/?search=tunctl | tunctl]].  I'm going to make the (possibly unfair) assumption that you know how to install Slackware packages from slackbuilds.+==== dispositivo tap0 ====
  
-Once tunctl is installed, edit /etc/rc.d/rc.inet1, find the following lines:+Habiendo instalado una segunda máquina virtual Slackware con dos tarjetas ethernet, solo una de las cuales está activa, necesitamos hacer algunas cosas adicionales antes de hablar sobre OpenVPN. 
 + 
 +<del>Having installed a nice shiny 2nd Slackware virtual machine with two ethernet cards, only one of which is active we need to do some extra stuff before we talk about OpenVPN.</del> 
 + 
 +El primer paso es instalar [[https://slackbuilds.org/repository/14.2/network/tunctl/?search=tunctl | tunctl]]. 
 +Voy a hacer la suposición (posiblemente injusta) de que sabes cómo instalar paquetes de Slackware desde slackbuilds. 
 +<del>The first step is to install [[https://slackbuilds.org/repository/14.2/network/tunctl/?search=tunctl | tunctl]].  I'm going to make the (possibly unfair) assumption that you know how to install Slackware packages from slackbuilds. 
 +</del> 
 + 
 +Una vez instalado tunctl, edita el archivo /etc/rc.d/rc.inet1, busca las siguientes líneas: 
 + 
 +<del>Once tunctl is installed, edit /etc/rc.d/rc.inet1, find the following lines: 
 +</del>
  
 <code> <code>
-Function to start the network:+Funciones para iniciar la red:
 start() { start() {
   lo_up   lo_up
Línea 116: Línea 140:
 </code> </code>
  
-Make them say:+Haz que diga: 
 +<del>Make them say:</del>
  
 <code> <code>
-Function to start the network:+Funciones para iniciar la red:
 start() { start() {
   lo_up   lo_up
Línea 125: Línea 150:
 ... ...
 </code> </code>
 +Esto creará (en el arranque) un dispositivo tap0 con los permisos correctos de modo que OpenVPN pueda acceder a él y, más concretamente, lo  creará antes de que comience la configuración de puentes en los scripts de inicio de Slackware. También se podría crear en rc.local pero se iniciaría demasiado tarde.
  
-This will (on boot) create a tap0 device with the correct permissions such that OpenVPN can access it and, more to the point,  +<del>This will (on boot) create a tap0 device with the correct permissions such that OpenVPN can access it and, more to the point,  
-it will create it before any of the bridging configuration stuff in the Slackware init scripts kicks in.  rc.local would have it created way too late.+it will create it before any of the bridging configuration stuff in the Slackware init scripts kicks in.  rc.local would have it created way too late.</del>
  
-==== Bridging setup ====+==== configuración del puente ====
  
-OKso now we are talking about [[https://wiki.linuxfoundation.org/networking/bridge | kernel network bridging]], not the ethernet bridging that's the subject of this article.  It's a sad fact that even though we have a NIC purposely allocated to the task of talking to our private network, i.e. not shared with any other traffic, we still need to create a kernel bridge in order for OpenVPN to talk properly to the NIC, in other words we can't tell OpenVPN to just 'use eth1' (oh that it were so simple).  It wants a 'tap' And a tap can only talk to a NIC via a bridge.  So let's have a look at the network config in Slackware.+Okahora estamos hablando acerca de [[https://wiki.linuxfoundation.org/networking/bridge | kernel network bridging]], no del puente ethernet que es el tema de este artículo.
  
-For eth0 in /etc/rc.d/rc.inet1.conf you are going to now have a setup something like thiscourteously supplied by the Slackware netconfig script:+<del>OK, so now we are talking about [[https://wiki.linuxfoundation.org/networking/bridge | kernel network bridging]], not the ethernet bridging that's the subject of this article.</del> 
 +Este es un hecho triste que a pesar de que tenemos una NIC asignada a propósito a la tare de hablar con nuestra red privada, es decir, no se comparte con ningún otro tráfico, todavía necesitamos crear un puente del kernel para que OpenVPN pueda hablar correctamente con la NICEn otras palabras, no podemos decirle a OpenVPN que simplemente 'usá eth1' (o que sea tan simple).  
 +<del>It's a sad fact that even though we have a NIC purposely allocated to the task of talking to our private networki.e. not shared with any other traffic, we still need to create a kernel bridge in order for OpenVPN to talk properly to the NIC, in other words we can't tell OpenVPN to just 'use eth1' (oh that it were so simple). 
 +</del> 
 +Esto quiere un 'tap'. Y un tap puede solo hablar a un dispositivo NIC a través de un puente. 
 +Así que echemos un vistazo a la configuración de red en Slackware
 +<del>It wants a 'tap' And a tap can only talk to a NIC via a bridge.  So let's have a look at the network config in Slackware.</del>
  
 +Para eth0 en /etc/rc.d/rc.inet1.conf ahora tendrá una configuración como esta, suministrado con cortesía por el script netconfig de Slackware;
 +<del>For eth0 in /etc/rc.d/rc.inet1.conf you are going to now have a setup something like this, courteously supplied by the Slackware netconfig script:
 +</del>
 <code> <code>
 IPADDR[0]="" IPADDR[0]=""
Línea 141: Línea 176:
 ... ...
 </code> </code>
- +O puede tener una dirección IP estática. Debes tener *algo*. Ahora desplácese hacia abajo a la sección sobre puentes: 
-Or you may have a static IP address.  You should have *something*.  Now scroll down to the section on bridging: +<del>Or you may have a static IP address.  You should have *something*.  Now scroll down to the section on bridging: 
 +</del>
 <code> <code>
-Example of how to configure a bridge+Ejemplo de como configurar un puente
-# Note the added "BRNICS" variable which contains a space-separated list +# Note el agregado de la variable "BRNICS" la cual contiene un lista separada por espacios 
-of the physical network interfaces you want to add to the bridge.+de las interfaces de red físicas que tu quieres agregar a el puente.
 ... ...
 </code> </code>
  
-Just below that you want the following to appear:+Justo debajo se desea que aparezca lo siguiente: 
 +<del>Just below that you want the following to appear:</del>
  
 <code> <code>
Línea 159: Línea 195:
 </code> </code>
  
-Be careful with the numbers.  It's the the square brackets which are telling Slackware this is the 2nd device we're configuring as a bridge, and we want to add eth1 to the bridge along with the tap0 device.  Slackware doesn't configure the eth1 device, we don't even need to bring it up or otherwise refer to it in the config files as it's slave to the bridge.+Se cuidadoso con los números. Los corchetes son los que le dicen a Slackware que este es el segundo dispositivo que configuramos como puente, y nosotros queremos agregar el dispositivo eth1 a el puente junto con el dispositivo tap0. 
 +<del>Be careful with the numbers.  It's the the square brackets which are telling Slackware this is the 2nd device we're configuring as a bridge, and we want to add eth1 to the bridge along with the tap0 device.</del> 
 +Slackware no configura el dispositivo eth1, ni siquiera necesitamos mencionarlo o referirlo de otra manera en los archivos de configuración como esclavo del puente. 
 +  Slackware doesn't configure the eth1 device, we don't even need to bring it up or otherwise refer to it in the config files as it's slave to the bridge.</del>
  
 <note> <note>
-Some people might configure br0 as br1 hereto indicate it's connected to the second NIC and keep them the same You can do that And you can change the name of tap0 as well if you wantexperience tells me it's best to always use the lowest numbers for everything regardless of what they do For meat leastit reduces the confusion.+Algunas personas pueden configurar aquí br0 como br1, para indicar que esta conectado al segundo NIC y mantenerlos igualUsted puede hacer estoTambién puedes cambiar el nombre de tap0 si tu lo deseasla experiencia me dice que es mejor usar siempre números bajos para todo independientemente de lo que haganPara míal menosreduce la confusión.
 </note> </note>
  
-You don't have to set the IP address to 0.0.0.0but it'a handy way of making the bridge come 'up' without giving it an IP address, and something that is supposed to simply sit there forwarding ethernet frames has no business having an IP address of its own.  If you don't set any address at all you can do 'ifconfig br0 up' at some later point.+<note> 
 +Some people might configure br0 as br1 here, to indicate it's connected to the second NIC and keep them the same You can do that And you can change the name of tap0 as well if you wantexperience tells me it'best to always use the lowest numbers for everything regardless of what they do.  For me, at least, it reduces the confusion. 
 +</note>
  
-When you boot with this configurationyou should check that br0 is up with+No necesitas configurar la dirección IP a 0.0.0.0pero esto es una forma práctica de hacer que el puente sea levantado sin darle una dirección ip, y no es un problema. 
 +Si usted no configura alguna dirección ip, usted puede hacer 'ifconfig br0 up' posteriormente. 
 +<del>You don't have to set the IP address to 0.0.0.0, but it's a handy way of making the bridge come 'up' without giving it an IP address, and something that is supposed to simply sit there forwarding ethernet frames has no business having an IP address of its own.  If you don't set any address at all you can do 'ifconfig br0 up' at some later point. 
 +</del>
  
 +Cuando se arranca con esta configuración, usted debé chequear que br0 esta arrib con:
 +<del>When you boot with this configuration, you should check that br0 is up with
 +</del>
 <code> <code>
 # ifconfig br0 # ifconfig br0
 </code> </code>
  
-And you can also check the bridge with 'brctl show br0' and it should show something like this: +y usted puede también chequear el puente con 'brctl show br0' y se debería mostrar algo como esto: 
 +<del>And you can also check the bridge with 'brctl show br0' and it should show something like this: 
 +</del>
 <code> <code>
 # brctl show br0 # brctl show br0
Línea 181: Línea 229:
                                                         tap0                                                         tap0
 </code> </code>
 +Así que eso está hecho la configuración de puente. Ahora OpenVPN (cuando este eventualmente configurado) podrá comunicarse con la red privada, en este ejemplo, 'slacknet' sin problemas, incluso si solo tiene 'nadie' como nombre de usuario.
  
-So that's done the bridging config.  Now OpenVPN (when it's eventually configured) will talk nicely to the private network aka 'slacknet' without any trouble, even if it only has 'nobody' as a username.+<del>So that's done the bridging config.  Now OpenVPN (when it's eventually configured) will talk nicely to the private network aka 'slacknet' without any trouble, even if it only has 'nobody' as a username. 
 +</del> 
 +==== Configuración de OpenVPN ====
  
-==== OpenVPN setup ====+Así que esta es la parte en la que puedo descansar tranquilamente 'sobre los hombros de gigantes' por así decirlo. Por favor, configure su PKI para un servidor OpenVPN siguiendo [[es:howtos:network_services:openvpn#creating_a_public_key_infrastructure_pki_using_the_easy-rsa_scripts | guide in the OpenVPN howto]]. 
 +Siga toda la sección 5 para tener un conjunto de claves públicas y privadas para el servidor. 
 +No te preocupes por crear el archivo de configuración para hacer referencias a ellos, ya que lo haremos aquí.
  
-So this is the part where I can just rest easy 'on the shoulders of giants' so to speak.  Please setup your the PKI stuff for an OpenVPN server by following the +¿Esta preparado? bien. 
 + 
 +<del>So this is the part where I can just rest easy 'on the shoulders of giants' so to speak.  Please setup your the PKI stuff for an OpenVPN server by following the 
 [[howtos:network_services:openvpn#creating_a_public_key_infrastructure_pki_using_the_easy-rsa_scripts | guide in the OpenVPN howto]].  Follow all of section 5 so you have a set of public and private keys for the server.  Don't worry about creating the config file to reference them from though as we'll do that back here. [[howtos:network_services:openvpn#creating_a_public_key_infrastructure_pki_using_the_easy-rsa_scripts | guide in the OpenVPN howto]].  Follow all of section 5 so you have a set of public and private keys for the server.  Don't worry about creating the config file to reference them from though as we'll do that back here.
  
-Ready?  Good.+Ready?  Good.</del> 
 + 
 +Mi /etc/openvpn/server.conf 
  
 So my /etc/openvpn/server.conf is a little simpler than the one in the OpenVPN howto.  We don't care about any of the routing stuff, and I've removed all the comments for brevity.  You can always check options in the manual page for OpenVPN if you want but most are self-explanatory. So my /etc/openvpn/server.conf is a little simpler than the one in the OpenVPN howto.  We don't care about any of the routing stuff, and I've removed all the comments for brevity.  You can always check options in the manual page for OpenVPN if you want but most are self-explanatory.
Línea 256: Línea 313:
 So once all four (yes!) virtual machines are up and running, it should be possible (if all is working) to boot the Private Client and get an IP address in the right range, i.e. between 10.0.0.50 and 10.0.0.70.  Pay close attention to /var/logs/openvpn.log on 'Server Gateway' and of course the messages displayed when running openvpn on 'Client Gateway' as they should tell you what's wrong.  OpenVPN is pretty good like that.  The paranoid will also want to check /var/state/dnsmasq/dnsmasq.leases on 'Private Server' to reassure themselves that all's well and we are actually talking across the bridge. So once all four (yes!) virtual machines are up and running, it should be possible (if all is working) to boot the Private Client and get an IP address in the right range, i.e. between 10.0.0.50 and 10.0.0.70.  Pay close attention to /var/logs/openvpn.log on 'Server Gateway' and of course the messages displayed when running openvpn on 'Client Gateway' as they should tell you what's wrong.  OpenVPN is pretty good like that.  The paranoid will also want to check /var/state/dnsmasq/dnsmasq.leases on 'Private Server' to reassure themselves that all's well and we are actually talking across the bridge.
  
-===== Consolidation =====+===== Consolidación =====
  
 As I explained in the introduction, it's possible to test all this out without the 'Private server', and combine the function of 'Private Server' and 'Server gateway' in a single machine.  Read on to discover how. As I explained in the introduction, it's possible to test all this out without the 'Private server', and combine the function of 'Private Server' and 'Server gateway' in a single machine.  Read on to discover how.
 es:howtos:network_services:ethernet_bridging_with_openvpn ()