Modo Tunel ‣ Nueva Cabecera IP Con Destino Entre Gateways Modo Tunel ‣ El Paquete Orginal Se Transporta Entero Ip

Total Page:16

File Type:pdf, Size:1020Kb

Modo Tunel ‣ Nueva Cabecera IP Con Destino Entre Gateways Modo Tunel ‣ El Paquete Orginal Se Transporta Entero Ip Redes privadas virtuales VPN Seguridad en el canal ‣ En ocasiones queremos extender la red de una empresa más allá de los limites del edificio ‣ Antiguamente se usaban lineas telefónicas alquiladas para unir routers en las sedes remotas y tener un enlace. (que se puede pinchar... o podemos fiarnos del operador) ‣ Ahora surge la posibilidad de enviar esos paquetes a través de Internet Cobertura en cualquier parte (no hace falta tener preparada la linea alquilada) Ahorro (no hace falta pagar la linea alquilada) Seguridad (podemos cifrar las comunicaciones y olvidarnos de si pinchan o no el cable) mi red Internet mi red Redes privadas virtuales (VPN) Dos cuestiones a resolver ‣ ¿Como hacemos para que las redes de diferentes sedes se comporten como si estuvieran en la misma red? ‣ ¿Como protegemos nuestras comunicaciones de los observadores? ‣ Necesitamos Autentificacion/Autorización (y Accounting) ‣ Necesitamos cifrado mi red Internet mi red Tunneling Idea basica… ‣ El caso normal ‣ Routers son elementos con su propia IP, pueden comunicarse soft soft Idea basica… ‣ Los routers se comunican los paquetes, como si tuvieran un enlace directo que en realidad es virtual soft soft ‣ Entre los routers los paquetes van dentro de otros paquetes soft soft ‣ A esto lo llamamos un TUNEL Túneles, para que? ‣ Simplificar enrutamiento ‣ Controlar acceso ‣ Transportar direcciones o protocolos por zonas que no las soportan (direcciones privadas, IPv6…) ‣ Cifrar la información que va dentro del túnel R3 R2 E2 R4 E1 R1 El paquete p : E1 > R1 > R4 > E2 Pero R1 > R4 es que R1 genera un paquete q El paquete q : R1 > R2 > R3 > R4 Esto no es nuevo… ‣ PPP y lineas telefónicas IP Red Telefónica IP T T Modem T Modem T IP en PPP Red Telefónica T T Modem T Sede 2 Sede 1 Modem T IP en PPP Esto no es nuevo… ‣ Enlaces virtuales IP IP Enlace PPP IP en PPP Enlace PPP Sede 2 Sede 1 IP en PPP ‣ Y si transportamos los paquetes PPP en otra cosa que no sea una llamada telefónica Protocolos de túnel ‣ Según que es lo que transportamos ‣ Paquetes de nivel de enlace: túneles de nivel 2 enlace ‣ Paquetes de nivel de red: túneles de nivel 3 red ‣ Datos de aplicación o conexiones: tuneles de transporte ‣ Según como lo transportemos ‣ Dentro de paquetes o conexiones ‣ Muchos protocolos ‣ IPIP, GRE, MPLS, … ‣ PPTP, L2F, L2TP … ‣ IPsec ‣ openvpn, n2n, ssh, socat … ‣ … Túneles con SSH Ejemplo: Tuneles sobre SSH Tunel de nivel de transporte sobre SSH ‣ Redireccionar un puerto local $ ssh usuario@host -L puertolocal:destino:puerto ‣ Escenario con ssh permitido pero puerto P filtrado ‣ Para el destino la conexion viene de H2 sshd servicio P puerto ssh puertolocal PL Tuneles sobre SSH Tunel de nivel de transporte sobre SSH ‣ Redireccionar un puerto remoto $ ssh usuario@host -R puertoremoto:destino:puerto ‣ Igual que en el caso anterior pero redirecciona puertos del puertoremoto servidor hacia la red del cliente de ssh sshd PR ‣ Se puede usar SSH para proteger ssh servicios clasicos P telnet Ejemplos Tuneles de nivel de enlace sobre ssh (PPP sobre ssh) ‣ Conexión ssh y un pppd en cada extremo $ pppd pty “ssh usuario@host pppd” ‣ Puedo enviar paquetes IP a un PC de mi red que luego actue como router ‣ Uso: VPN construida a mano con solo un servidor ssh y pppd ‣ Uso : puerta de entrada a traves de cualquier firewall que soporte conexiones entrantes ssh pppd pppd ssh mi red Internet ssh Ejemplos Tuneles con tun/tap sobre ssh ‣ Opcion -w $ ssh -w 2:5 usuario@host $ ifconfig tun2 10.3.1.1/24 $ ifconfig tun5 10.3.1.3/24 tun2 tun5 ssh mi red Internet ssh Túneles con SOCAT ¿Que es un interfaz de red? TCP/UDP ‣ Que es para el sistema operativo eth0 ? eth1 ? ppp0 ? IP ‣ Es un modulo al que IP puede entregar paquetes o del que los puede recibir ‣ Cada interfaz tiene código diferente para eth0 eth1 ppp0 obtener o procesar paquetes ‣ Hay modulos para intercambiar paquetes entre IP y un programa TCP/UDP ‣ Lo que escribo en /dev/tun0 es interpretado como que ha llegado un paquete que se le entregara a IP IP ‣ Lo que envia IP a través de tun0 lo leerá un programa que tenga abierto/dev/tun0 tun0 eth0 ‣ TUN da los paquetes a nivel 3 IP ‣ TAP da los paquetes a nivel 2 ethernet /dev/tun0 Como funciona un túnel en el SO Datos para Datos para 72.2.1.5 72.2.1.5 TCP/UDP TCP/UDP IP IP 55.0.1.3 72.2.1.5 eth0 eth0 Internet global eth eth ‣ Funcionamiento normal de IP Como funciona un túnel en el SO TCP/UDP TCP/UDP 192.168.1.1 192.168.1.2 IP IP tun0 tun0 55.0.1.3 72.2.1.5 eth0 eth0 Internet global eth eth ‣ Tenemos interfazes para hacer un enlace virtual ‣ IP cada interfaz esta en una subred y tiene una dirección IP Como funciona un túnel en el SO Datos para 192.168.1.2 TCP/UDP TCP/UDP 192.168.1.1 192.168.1.2 IP IP tun0 tun0 55.0.1.3 72.2.1.5 eth0 eth0 Internet global eth eth ‣ Si envío a una IP del enlace virtual el paquete va a tun que lo entrega /dev/tun al programa que este leyendo Como funciona un túnel en el SO envia a programa túnel Datos para 72.2.1.5 192.168.1.1 192.168.1.2 esta en 72.2.1.5 TCP/UDP TCP/UDP 192.168.1.1 192.168.1.2 IP IP tun0 tun0 55.0.1.3 72.2.1.5 eth0 eth0 Internet global eth eth ‣ Habra un software haciendo el túnel que recibira el paquete y tiene que meterlo en el tunel. ‣ Decidir a quien enviárselo, cifrarlo… Como funciona un túnel en el SO Datos para programa túnel envia a programa túnel 192.168.1.2 Datos para 192.168.1.1 extraigo el paquete 72.2.1.5 llegan desde 192.168.1.2 esta en 72.2.1.5 es para 192.168.1.2 192.168.1.1 TCP/UDP TCP/UDP 192.168.1.1 192.168.1.2 IP IP tun0 tun0 55.0.1.3 72.2.1.5 eth0 eth0 Internet global eth eth ‣ El receptor del mensaje es el software de túnel que lo entregará al /dev/tun del destino ‣ El kernel recibe un paquete en un interfaz y lo entrega al destino ‣ El programa escuchando en 192.168.1.2 recibe los datos Como funciona un túnel en el SO ‣ IP ve dos interfaces no sabe que uno en realidad se hace con envíos a través del otro ‣ En un interfaz soy vecino de 192.168.1.2 TCP/UDP TCP/UDP 192.168.1.1 192.168.1.2 IP red virtual 192.168.1.0/24 IP tun0 tun0 55.0.1.3 72.2.1.5 eth0 eth0 Internet global eth eth ‣ Los túneles tienen direcciones IP internas del túnel ‣ Que no son las mismas que los extremos del túnel ‣ Los extremos del túnel tienen que poder comunicarse antes de que se cree el túnel The power of socat ‣ Equivalente a nc socat STDIN TCP:servidor:puerto socat STDIN TCP-LISTEN:puerto ‣ Abre dos interfaces genéricos ‣ En paralelo lee todo lo que aparece en cada uno y lo envia al otro SOCAT ‣ puede ser ‣ Un socket TCP o UDP cliente o servidor ‣ Abrir un fichero (incluyendo /dev/tun /dev/tap) ‣ Abrir otro programa ‣ Hacer una conexión SSL ‣ Prácticamente cualquier cosa en UNIX Usando socat para un túnel ‣ Ejemplo En 72.2.1.5 $ socat TUN:10.3.1.3/24 TCP-LISTEN:5000 En 55.0.1.3 $ socat TUN:10.3.1.1/24 TCP:72.2.1.5:5000 SOCAT SOCAT abre CNX a 10.3.1.1 túnel 10.3.1.3 escucha en 5000 72.2.1.5 : 5000 72.2.1.5 55.0.1.3 Internet global eth eth Cifrando con SSL ‣ Ejemplo En 72.2.1.5 $ socat TUN:10.3.1.3/24 OPENSSL-LISTEN:5000 En 55.0.1.3 $ socat TUN:10.3.1.1/24 OPENSSL:72.2.1.5:5000 SOCAT SOCAT abre CNX a 10.3.1.1 túnel cifrado 10.3.1.3 escucha en 5000 72.2.1.5 : 5000 72.2.1.5 55.0.1.3 Internet global eth eth ‣ Pero habra que añadir parámetros a OPENSSL para decirle que clave privada usamos o de que certificado nos fiamos… se deja como ejercicio Mas variedades con socat ‣ OPENSSL ‣ Hay que especificar la clave privada en el servidor ‣ Hay que especificar de quien nos fiamos en el cliente ‣ TAP en lugar de TUN hace el túnel de nivel 2 ‣ Envia la trama ethernet y hay ARP con lo que puede haber una red con más direcciones ‣ UDP en lugar de TCP ‣ Cada paquete va en un paquete UDP ‣ Menos fiabilidad pero más rápido ‣ Cuidado la mayoría de estos hacen túnel pero no cifran ‣ Tampoco hay autentificación VPN Red privada virtual ‣ Construir una red privada sobre la red pública ‣ Necesitamos ‣ Tuneling ‣ Autentificación ‣ Control de acceso ‣ Seguridad de los datos (encriptación) Arquitecturas de VPNs mi red Internet mi red LAN-to-LAN End-to-LAN POP-to-POP POP = Point of Presence router del operador que nos vende el servicio de VPN ‣ Según las necesidades el tunel para la VPN puede realizarse desde un gateway (router) de la empresa o del proveedor y llegar hasta un gateway o bien llegar hasta el ordenador final ‣ Según quién realice el tunel tendremos diferente protección y diferente gestión de la red Tipos de VPNs mi red mi red Internet mi red ‣ Interna (Site-to-site): une dos o más redes internas como si fueran una sola red ‣ Acceso: permite el acceso de un cliente que esta en una red insegura.
Recommended publications
  • N2N: a Layer Two Peer-To-Peer VPN
    N2N: A Layer Two Peer-to-Peer VPN Luca Deri1, Richard Andrews2 ntop.org, Pisa, Italy1 Symstream Technologies, Melbourne, Australia2 {deri, andrews}@ntop.org Abstract. The Internet was originally designed as a flat data network delivering a multitude of protocols and services between equal peers. Currently, after an explosive growth fostered by enormous and heterogeneous economic interests, it has become a constrained network severely enforcing client-server communication where addressing plans, packet routing, security policies and users’ reachability are almost entirely managed and limited by access providers. From the user’s perspective, the Internet is not an open transport system, but rather a telephony-like communication medium for content consumption. This paper describes the design and implementation of a new type of peer-to- peer virtual private network that can allow users to overcome some of these limitations. N2N users can create and manage their own secure and geographically distributed overlay network without the need for central administration, typical of most virtual private network systems. Keywords: Virtual private network, peer-to-peer, network overlay. 1. Motivation and Scope of Work Irony pervades many pages of history, and computing history is no exception. Once personal computing had won the market battle against mainframe-based computing, the commercial evolution of the Internet in the nineties stepped the computing world back to a substantially rigid client-server scheme. While it is true that the today’s Internet serves as a good transport system for supplying a plethora of data interchange services, virtually all of them are delivered by a client-server model, whether they are centralised or distributed, pay-per-use or virtually free [1].
    [Show full text]
  • Internet Telephony PBX System IPX-2200/IPX-2500
    Internet Telephony PBX System IPX-2200/IPX-2500 Internet Telephony PBX System IPX-2200 IPX-2500 1 Internet Telephony PBX System IPX-2200/IPX-2500 Copyright Copyright (C) 2016 PLANET Technology Corp. All rights reserved. The products and programs described in this User’s Manual are licensed products of PLANET Technology. This User’s Manual contains proprietary information protected by copyright, and this User’s Manual and all accompanying hardware, software, and documentation are copyrighted. No part of this User’s Manual may be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form by any means by electronic or mechanical including photocopying, recording, or information storage and retrieval systems, for any purpose other than the purchaser's personal use, and without the prior written permission of PLANET Technology. Disclaimer PLANET Technology does not warrant that the hardware will work properly in all environments and applications, and makes no warranty and representation, either implied or expressed, with respect to the quality, performance, merchantability, or fitness for a particular purpose. PLANET has made every effort to ensure that this User’s Manual is accurate; PLANET disclaims liability for any inaccuracies or omissions that may have occurred. Information in this User’s Manual is subject to change without notice and does not represent a commitment on the part of PLANET. PLANET assumes no responsibility for any inaccuracies that may be contained in this User’s Manual. PLANET makes no commitment to update or keep current the information in this User’s Manual, and reserves the right to make improvements to this User’s Manual and/or to the products described in this User’s Manual, at any time without notice.
    [Show full text]
  • Virtual Private Networks for Peer-To-Peer Infrastructures
    Technische Universit¨atDarmstadt Department of Computer Science Prof. Dr. Michael Waidner Virtual Private Networks for Peer-to-Peer Infrastructures Diploma Thesis Submitted by Hiro Dudani <[email protected]> on 2012-11-30 Supervisor: Dipl.-Inform. Nicolai Kuntze In cooperation with: Fraunhofer SIT f¨urPapa ii Ehrenw¨ortlicheErkl¨arung(Affidavit) Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ¨ahnlicher Form noch keiner Pr¨ufungsbeh¨ordevorgelegen. Hiro Dudani Neu-Isenburg, am 29.11.2012 iii Abstract The Nanodatacenters project aims to complement the paradigm of existing centralized server farms with a high number of small storage and communication devices located at the edges of the network. Utilizing previously unused resources like broadband internet access bandwith and idling set-top boxes, these nodes are able to host applications from different content providers offering various kinds of services, such as Video on Demand or online gaming, to end users. This setting does pose particular security challenges. As the devices operate under physical control of the end users, their integrity has be ensured and must be able to be verified by the network. This is achieved through the functionality of Trusted Com- puting. Additionally, the domains of the different content providers have to be isolated in such a way that an attacker cannot use one of them as a foothold to compromise or snoop on the operation of the network or another isolated domain.
    [Show full text]
  • N2N: a Layer Two Peer-To-Peer VPN
    N2N: A Layer Two Peer-to-Peer VPN Luca Deri1 and Richard Andrews2 1 ntop.org, Pisa, Italy 2 Symstream Technologies, Melbourne, Australia {deri,andrews}@ntop.org Abstract. The Internet was originally designed as a flat data network delivering a multitude of protocols and services between equal peers. Currently, after an explosive growth fostered by enormous and heterogeneous economic interests, it has become a constrained network severely enforcing client-server communication where addressing plans, packet routing, security policies and users’ reachability are almost entirely managed and limited by access providers. From the user’s perspective, the Internet is not an open transport system, but rather a telephony-like communication medium for content consumption. This paper describes the design and implementation of a new type of peer- to-peer virtual private network that can allow users to overcome some of these limitations. N2N users can create and manage their own secure and geographically distributed overlay network without the need for central administration, typical of most virtual private network systems. Keywords: Virtual private network, peer-to-peer, network overlay. 1 Motivation and Scope of Work Irony pervades many pages of history, and computing history is no exception. Once personal computing had won the market battle against mainframe-based computing, the commercial evolution of the Internet in the nineties stepped the computing world back to a substantially rigid client-server scheme. While it is true that the today’s Internet serves as a good transport system for supplying a plethora of data interchange services, virtually all of them are delivered by a client-server model, whether they are centralised or distributed, pay-per-use or virtually free [1].
    [Show full text]
  • N2N: Layer Two Peer-To-Peer VPN
    N2N: Layer Two Peer-to-Peer VPN Luca Deri <deri@{unipi.it,ntop.org}> The Internet Isn’t Really Open • Was originally been designed as a flat data network delivering a multitude of protocols and services between peers. • Is actually a constrained network severely enforcing client-server communication. • Addressing plans, packet routing, security policies and users’ reachability issues are entirely managed and limited by access providers. Luca Deri <[email protected]> - April 2008 User’s View of the Internet • NAT devices mask the user’s IP identity and limit peers accessibility. • No control over the connection configuration, totally managed by ISPs. • Firewall greatly reduce the possibility of a user being contacted by a direct session opened elsewhere over the Internet. Luca Deri <[email protected]> - April 2008 In a Nutshell... The Internet is a large “department store” where users can go shopping for communication services, but it can’t be easily used as a geographically distributed LAN except at the price of setting up static VPNs relying upon “premium fee” access services. Luca Deri <[email protected]> - April 2008 Vision • The internet should be a “transparent” IP- based transport for users, not a geographical/ ISP constrain. • Users should control/create their community networks (today network administrators do). • Security is a community to community policy (today it has to do with IP addresses, ports, NAT..). • The focus is on the service/content (email, song etc.) rather than on the host that provides it. Luca Deri <[email protected]> - April 2008 What is n2n ? • A layer-two peer-to-peer virtual private network (VPN) which allows users to exploit features typical of p2p applications at network instead of application level.
    [Show full text]
  • SEMOS: a Middleware for Providing Secure and Mobility-Aware Sessions Over a P2P Overlay Network
    SEMOS: A Middleware for Providing Secure and Mobility-Aware Sessions over a P2P Overlay Network B Daouda Ahmat1,2( ), Mahamat Barka2, and Damien Magoni3 1 Virtual University of Chad, N’Djamena, Chad [email protected] 2 University of N’Djamena, N’Djamena, Chad [email protected] 3 University of Bordeaux – LaBRI, Bordeaux, France [email protected] Abstract. Mobility and security are major features for both current and future network infrastructures. Nevertheless, the integration of mobility in traditional virtual private networks is difficult due to the costs of re-establishing broken secure tunnels and restarting broken connections. Besides session recovery costs, renegotiation steps also present inherent vulnerabilities. In order to address these issues, we propose a new dis- tributed mobile VPN system called SEcured MObile Session (SEMOS). Based upon our CLOAK peer-to-peer overlay architecture, SEMOS pro- vides security services to the application layer connections of mobile users. Secure and resilient sessions allow user connections to survive net- work failures as opposed to regular transport layer secured connections used by traditional VPN protocols. Keywords: Connectivity · Mobility · Overlay · P2P · VPN · Security 1 Introduction Mobile devices and wireless networks have progressively provided increased con- nectivity for users. However, such extended connectivity often comes at the expense of vulnerabilities to attacks such as eavesdropping. Malicious users can infiltrate public open networks and attack legitimate traffic. Virtual Pri- vate Networks (VPN) are offering high security to the network traffic [1]. Tra- ditionally, these systems allow the user to securely and remotely communicate with its Intranet through insecure public networks such as the Internet.
    [Show full text]
  • City Research Online
    Sajjad, Ali (2015). A secure and scalable communication framework for inter-cloud services. (Unpublished Post-Doctoral thesis, City University London) City Research Online Original citation: Sajjad, Ali (2015). A secure and scalable communication framework for inter- cloud services. (Unpublished Post-Doctoral thesis, City University London) Permanent City Research Online URL: http://openaccess.city.ac.uk/14415/ Copyright & reuse City University London has developed City Research Online so that its users may access the research outputs of City University London's staff. Copyright © and Moral Rights for this paper are retained by the individual author(s) and/ or other copyright holders. All material in City Research Online is checked for eligibility for copyright before being made available in the live archive. URLs from City Research Online may be freely distributed and linked to from other web pages. Versions of research The version in City Research Online may differ from the final published version. Users are advised to check the Permanent City Research Online URL above for the status of the paper. Enquiries If you have any enquiries about any aspect of City Research Online, or if you wish to make contact with the author(s) of this paper, please email the team at [email protected]. A Secure and Scalable Communication Framework for Inter-Cloud Services Ali Sajjad School of Mathematics, Computer Science & Engineering City University London This dissertation is submitted for the degree of Doctor of Philosophy September 2015 THE FOLLOWING PARTS OF THIS THESIS HAVE BEEN REDACTED FOR COPYRIGHT REASONS: p 7: Fig 1.2. International Data Corporation survey.
    [Show full text]
  • City Research Online
    City Research Online City, University of London Institutional Repository Citation: Rajarajan, M., Sajjad, A., Zisman, A., Nair, S. K. and Dimitrakos, T. (2012). Secure communication using dynamic VPN provisioning in an Inter-Cloud environment. Paper presented at the ICON 2012: 18th IEEE International Conference on Networks, 12 - 14 Dec 2012, Singapore. This is the unspecified version of the paper. This version of the publication may differ from the final published version. Permanent repository link: https://openaccess.city.ac.uk/id/eprint/1609/ Link to published version: Copyright: City Research Online aims to make research outputs of City, University of London available to a wider audience. Copyright and Moral Rights remain with the author(s) and/or copyright holders. URLs from City Research Online may be freely distributed and linked to. Reuse: Copies of full items can be used for personal research or study, educational, or not-for-profit purposes without prior permission or charge. Provided that the authors, title and full bibliographic details are credited, a hyperlink and/or URL is given for the original metadata page and the content is not changed in any way. City Research Online: http://openaccess.city.ac.uk/ [email protected] Secure communication using dynamic VPN provisioning in an Inter-Cloud environment Ali Sajjad, Andrea Zisman, Muttukrishnan Rajarajan Srijith K. Nair, Theo Dimitrakos City University London British Telecom, Innovate and Design EC1V 0HB London, UK BT Adastral Park, Ipswich, UK Email: Ali.Sajjad.1, A.Zisman, R.Muttukrishnan @city.ac.uk Email: srijith.nair, theo.dimitrakos @bt.com { } { } Abstract—Most of the current cloud computing platforms offer provisioning by offering a single abstraction for multiple coex- Infrastructure as a Service (IaaS) model, which aims to provision isting cloud architectures.
    [Show full text]
  • On the Design of Autonomic, Decentralized Vpns
    On the Design of Autonomic, Decentralized VPNs David Isaac Wolinsky, Kyungyong Lee, P. Oscar Boykin, Renato Figueiredo University of Florida Abstract—Decentralized and P2P (peer-to-peer) VPNs (virtual whereas existing decentralized solutions require manual con- private networks) have recently become quite popular for con- figuration of links between peers, which is beyond the scope necting users in small to medium collaborative environments, of Archer’s target users. Current P2P VPN approaches either such as academia, businesses, and homes. In the realm of VPNs, there exist centralized, decentralized, and P2P solutions. Central- lack scalability or proper security components to be useful for ized systems require a single entity to provide and manage VPN VPN approaches. server(s); decentralized approaches allow more than one entity to We began our original foray into user-friendly VPN ap- share the management responsibility for the VPN infrastructure, proaches with IPOP [2]. Previous work on IPOP focused on while existing P2P approaches rely on a centralized infrastructure the routing mechanisms and address allocation with multiple but allow users to bypass it to form direct low-latency, high- throughput links between peers. In this paper, we describe a virtual networks (VNs) sharing a single P2P overlay. Though novel VPN architecture that can claim to be both decentralized a shared has significant drawbacks as misconfigured or ma- and P2P, using methods that lower the entry barrier for VPN licious peers could disable the entire overlay, rendering all deployment compared to other VPN approaches. Our solution VPNs useless, and the system would have to be recreated as extends existing work on IP-over-P2P (IPOP) overlay networks to there exists no methods to remove the peer from the overlay.
    [Show full text]
  • TCP/IP Network Configuration Files: Domain Resolution Configuration
    TCP/IP Network Configuration Files: File Description /etc/resolve.conf List DNS servers for internet domain name resolution /etc/hosts Lists hosts to be resolved locally (not by DNS) List order of host name search. Typically look at local /etc/nsswitch.conf files, then NIS server, then DNS server. Specify network configuration. eg. Static IP, DHCP, NIS, Red Hat/Fedora/CentOS: /etc/sysconfig/network etc. Red Hat/Fedora/CentOS: /etc/sysconfig/network- Specify TCP network information. scripts/ifcfg-device Specify network configuration and devices. eg. Static IP Ubuntu/Debian: /etc/network/interfaces and info, DHCP, etc. Domain Resolution Configuration Files: • File: /etc/resolv.conf - host name resolver configuration file search name-of-domain.com - Name of your domain or ISP's domain if using their name server nameserver XXX.XXX.XXX.XXX - IP address of primary name server nameserver XXX.XXX.XXX.XXX - IP address of secondary name server • This configures Linux so that it knows which DNS server will be resolving domain names into IP addresses. If using DHCP client, this will automatically be sent to you by the ISP and loaded into this file as part of the DHCP protocol. If using a static IP address, ask the ISP or check another machine on your network. Red Hat/Fedora GUI: /usr/sbin/system-config-network (select tab "DNS". • File: /etc/hosts - locally resolve node names to IP addresses 127.0.0.1 your-node-name.your-domain.com localhost.localdomain localhost XXX.XXX.XXX.XXX node-name • Note when adding hosts to this file, place the fully qualified name first.
    [Show full text]
  • Today's Howtos Today's Howtos
    Published on Tux Machines (http://www.tuxmachines.org) Home > content > today's howtos today's howtos By Roy Schestowitz Created 18/01/2021 - 3:37pm Submitted by Roy Schestowitz on Monday 18th of January 2021 03:37:49 PM Filed under HowTos [1] Install Inkscape 1.0.2 In Ubuntu / LinuxMint / Debian | Tips On UNIX[2] Inkscape is a free and open-source professional vector graphics editor software that runs on Linux, Mac OS X, and Windows desktop computers. It is suitable for illustrators and web designers and it is an alternative to Adobe Illustrator. It supports many SVG features (markers, alpha blending, clones, etc..) and easy to use. How to enable PowerTools on CentOS 8 [3] The PowerTools repository, which is available on CentOS/RHEL 8, provides developer related tools and libraries. Some EPEL packages depend on packages available from PowerTools. Thus if you have set up the EPEL repository on your CentOS, it is recommended that you enable PowerTools as well. Install gscan2pdf 2.11.0 in Ubuntu / Linux Mmint [4] gscan2pdf a GUI tool used to produce PDF?s or DjVus from Scanned documents,gscan2pdf works on all Linux / BSD machines gscan2pdf team released a newer version 2.11.0 recently and yet to be updated in official Jeffrey Ratcliffe PPA for Ubuntu 20.04 and lower versions. This tutorial will be helpful for beginners to install gscan2pdf 2.11.0 in Ubuntu 20.10, Ubuntu 20.04, Linux Mint 20.1, and lower versions of Ubuntu and Linux Mint. How to set up WireGuard VPN server on Ubuntu 20.04 [5] Traditionally, VPN implementation has existed in two forms.
    [Show full text]
  • Softether VPN Server: マルチプロトコル対応の クロスプラットフォームなオープンソース VPN サーバ
    3 特集●ソフトウェア論文 SoftEther VPN Server: マルチプロトコル対応の クロスプラットフォームなオープンソース VPN サーバ 登 大遊 新城 靖 佐藤 聡 SoftEther VPN Server はマルチプロトコル対応のクロスプラットフォームなオープンソース VPN サーバソフト ウェアであり,既存の VPN サーバプログラムにない 2 つの特徴がある.1 つ目は,単一 VPN サーバインスタンス で複数の VPN プロトコルをサポートしている点にある.管理者は,複数の VPN プロトコルによる多種類の VPN デバイスからのリモートアクセスおよび拠点間接続を受付ける VPN サーバを容易に管理することができる.そのた めに,SoftEther VPN Server 内に L2 アダプタと呼ばれるモジュールを実装し,レイヤ 2 VPN プロトコルとレイ ヤ 3 VPN プロトコルとの間の通信を,共通のバスである仮想 L2 スイッチを経由させ,シームレスに実現にした. 2 つ目は,ユーザ管理やネットワークの機能を仮想化するマルチテナント機能である.これは,仮想ホスティング サービスのために必須である.本プログラムは複数の OS 間の移植性を有する.本プログラムは 2013 年 3 月から 2014 年 9 月までの間に,世界中で 242,000 回インストールされた実績を有する.また,異なる VPN プロトコル間 での通信速度実験では,従来の VPN プロトコルのネイティブな VPN サーバプログラムを組み合わせて用いた場合 と比較して高速な結果が得られた. SoftEther VPN Server is an open-source cross-platform multi-protocol VPN server which has two advan- tages over existing VPN servers. First, it supports multiple VPN protocols in a single VPN server instance. This makes it easy for an administrator to configure and manage a VPN server which supports remote access and site-to-site connection from a variety of VPN client devices. To realize that, SoftEther VPN Server includes a module called an L2 adapter to exchange messages between layer-3 VPN protocols and layer-2 VPN protocols seamlessly via common virtual L2 switches. The second advantage is that it can virtualize user management and networking, which is an essential function in multi-tenant virtual hosting. SoftEther VPN Server is portable among several operating systems. SoftEther VPN Server gained a total of 242,000 installations around the world from March 2013 to September 2014. The experimental result indicates that SoftEther VPN Server is faster than combinations of native VPN servers when exchanging messages between different VPN protocols.
    [Show full text]