Tag: vpn

kvpnc: client universal d’VPN per kde

Reading time: 1 – 2 minutes

GUI per clients d’VPN universal, suporta openVPN, cisco VPN client, FreeS/WAN (Linux 2.4.x), ipsec-tools support (Linux 2.6.x/BSD native), PPTP support (pptpclient). A més s’encarrega de fer la gestió de certificats i perfils dins d’un mateix tipus d’VPN. Realment molt útil si com jo heu de tenir a mà múltiples sistemes de connexió remots per diferents empreses i entorns de xarxa molt canviants.

screenshot-kvpnc.png

Val la pena que hi doneu un cop d’ull a la infinitat de funcionalitats que ofereix el programa. A més de ben segur que el podeu fer correr amb l’idioma que més us agradi i, com no, esta suportat al portage de gentoo. Així que ja només queda que proveu l’kvpnc i a veure si us agrada tan com a mi.

Tipus d’VPNs

Reading time: 7 – 12 minutes

Quan parlem d’VPNs gairebé tothom té clar perquè serveixen i què fan. El fotut és quan comencem a parlar de quin tipus d’implementació s’ha d’usar o s’ha usat per montar-la. Això fa que un munt de sigles comencin a saltar sobre la taula i al final si no tenim una molt bona base tècnica som incapaços d’entendre a què es refereixen. Aprofitant un article que ha aparegut a Network Systems DesignLine, de fet, és la primera part d’una serie encara incompleta anomenada Compare, design, and deploy VPNs–A tutorial–Part I he decidit fer un petit resum dels tipus d’VPN més comuns.

Dispositius d’una VPN

Per tal de poder parlar en propietat quan parlem dels elements de la VPN a continuació s’intenta definir una mica els dispositius que intervenen (o poden intervenir) en una VPN i on estan situats.

En el costat del client:

  • Customer (C) devices els dispositius C són simples, per exemple routers i switchos dins de la xarxa del client. Aquests dispositius no estan connectats a la xarxa del proveedor de servei. Aquests dispositius no saben distingir si estan o no dintre d’una VPN.
  • Customer Edge (CE) devices són els dispotius del client que donen conectivitat a la xarxa del proveedor de serveis.(via Provider Edge [PE]).
    • CE-r routers
    • CE-s switches

En les VPNs basades en CE, els dispositius CE si que estan disponibles per ser usades amb la VPN. Si les VPNs estan basades en els PE, els dispositius CE no estan disponibles per la VPN.

En les VPNs site-to-site, els dispositius del proveidor de serveis es poden classificar en:

  • Service Provider (P) devices els dispositius P com ara routers i switches dins de la xarxa del proveedor que no es connecten directament a la xarxa del client.
  • Service Provider Edge (PE) devices connectats directament a la xarxa del client a través dels dispositius CE. En les VPNs basades en PE aquests dispositius són visibles des de l’VPN, en les basades en CE no són visibles.
    • PE-r Provider Edge routers
    • PE-s Provider Edge switches
    • PE-rs Provider Edge devices that are capable of both routing and switching
VPNFigure1.gif

VPNs de capa 2, com ara VPLS, afegeixen un nivell a la gerarquia per ser més escalable (VPLS llavors passa a ser Hierarchical VPLS [H-VPLS]). En aquest cas, les funcionalitats dels dispositius PE, es divideixen en dos parts U-PE i N-PE.

Cal que no oblidem que els U-PE i els N-PE són equivalents al PE-CLE i al PE-POP, respectivament. Quan tenim un dispositiu PE-U de capa 2, podem referir-nos a ell com un MTU-s.

VPNFigure2.gif

Altres dispositius d’una VPN poden ser els NAS i els concentradors o gateways d’VPN. Un NAS és un dispositiu que fa d’interficie entre la xarxa d’accés (com ara PSTN) i les xarxes de conmutació de paquets (com ara un backbone IP). En un accés remot VPN el NAS pot treballar com a finalitzador de tunel.

Depenent del protocol usat per establir un accés remot el NAS es pot anomenar de diferents formes Layer Two Forwarding (L2F) Protocol NAS, Layer Two Tunneling Protocol (L2TP) Access Concentrator (LAC),o Point-to-Point Tunneling Protocol (PPTP) Access Concentrator (PAC).

Un gateway o concentrador d’VPNs actua com a punt final d’un túnel (VPN endpoint), especialment quan parlem d’accessos remots o VPNs basades en CEs (site-to-site).

Segons el protocol usat per aquests accessos remots el gateway o concentrador d’VPNs es pot anomenar, per exemple, L2F Home Gateway, L2TP Network Server (LNS), o PPTP Network Server (PNS).

Tecnologies i protocols usats en VPN del tipus Site-to-Site (o LAN-to-LAN)

En les VPNs site-to-site (o LAN-to-LAN) la informació del client viatja entre dispositius CE o entre dispositius PE.

  • IPsec són un conjunt de protocols dissenyats per protegir el tràfic IP entre gateways o hosts. Normalment s’usa aquest protocol per establir VPNs entre CEs.
  • GRE usat per fer túnels i transport de multiprotocols entre CEs. La seguretat de GRE és baixa o no inherent al protocol, però si volem podem aprofitar IPSsec per securitzar els túnels montats en GRE.
  • Draft Martini (Any Transport over MPLS–AToM) permet transportar protocols punt a punt com ara Frame Relay, ATM, Ethernet, Ethernet VLAN (802.1Q), High-Level Data Link Control (HDLC), i tràfic PPP sobre MPLS.
  • L2TPv3 permet transportar protocols com ara Frame Relay, ATM, Ethernet, Ethernet VLAN, HDLC, i tràfic PPP sobre IP o altres protocols de backbone.
  • IEEE 802.1Q tunneling (Q-in-Q) permet als proveedors de servei transportar tagged Ethernet (802.1Q) entre xarxes dels clients a través d’un backbone compartit. Per tal de fer això l’únic que es fa és tornar a afegir una altre etiqueta, a la afegida pel 802.1Q de la xarxa del client, aquesta vegada l’etiqueta 802.1Q és de la xarxa del proveedor.
  • MPLS LSPs (Label Switch Routers) els paquets es conmuten segons l’etiqueta afegida al paquet. LSPs poden rebre senyals de TDP, el LDP, o el RSVP.

Tecnologies i protocols usats en accessos remots

  • The Layer Two Forwarding (L2F) Protocol és propietari de Cisco. Bàsicament es va dissenyar per fer túnels PPP (o SLIP) per enllaços entre NAS i VPN gateways en oficines centrals. Els usuaris remots connecten al NAS, i les trames PPP de l’usuari remot són enviades pel túnel cap al VPN gateway.
  • The Point-to-Point Tunneling Protocol (PPTP) el van desenvolupar Microsoft, 3com i Ascend Communications. Com el L2F, el PPTP permet crear túnels per accessos remots a través de trames PPP entre un NAS i un VPN gateway. PPTP també permet crear túnels entre l’usari remot i el VPN gateway. PPP encapsula els paquets enviats a través dels túnels PPTP i sovint com a mètode de protecció s’usa MPPE.
  • The Layer 2 Tunneling Protocol versions 2 i 3 (L2TPv2/L2TPv3) és un estàndard de la IETF i combina les millors funcionalitats del L2F i el PPPTP. En un entorn d’accés remot, L2TP permet enviar trames PPP del client a través del NAS contra el VPN gateway o concentrador de túnels. L2TP té la seguretat com a element intrinsec, sovint s’usa IPSec per protegir-los.
  • IPSec permet establir túnels tipus site-to-site (LAN-to-LAN>), accessos remots o usuaris mòbils.
  • The Secure Sockets Layer (SSL) és un protocol de seguretat que va ser desenvolupat per Netscape Communications (SSL v1,v2 i v3). Ens permet crear enllaços remots segurs als usuaris mòbils. Funcionalment esta molt limitat, perquè no ens cal un client d’VPN. Cal no oblidar que TLS és un estàndard IETF molt similar la SSLv3.

Per tal de disfrutar d’un conjunt de funcionalitats més potent cal instal·lar un client d’VPN SSL específic.

Modelant i Caracteritzant una VPNs

Un bon mapa perno perdres en el món de les VPNs:

VPNFigure3.gif

VPNs creades pel proveedor o pel client

Exemples d’VPNs creades pels proveedors:

  • Virtual Private Wire Service (VPWS) VPNs
  • Virtual Private LAN Service (VPLS) VPNs
  • IP-Only Private LAN Service (IPLS) VPNs
  • BGP/MPLS (RFC4364/2547bis) VPNs (BGP/MPLS VPNs are also known as MPLS Layer 3 VPNs.)
  • Virtual Router (VR)-based VPNs
  • IPsec VPNs

Exemples d’VPN creades en el client:

  • GRE VPNs
  • IPsec VPNs
  • SSL VPNs

Site-to-Site i VPNs d’accés remot

Les VPNs les crei el proveidor o el client, només poden oferir dos tipus d’accés:

  • Site-to-site ofereixen connectivitat entre xarxes distants geograficament connectant-les com si es tractes d’una xarxa local. Bàsicament es ditingeixen dos tipus les intranet i les extranet segons si connecten xarxes de la mateixa organització o de diferents organitzacions, respectivament.
VPNFigure4.gif
  • Accés remot també anomenades VPNs d’accés permeten a un usuari mòbil o domèstic accedir a la xarxa de l’organització i accedir als seus recursos de xarxa com si estiguessis físicament a la xarxa.
VPNFigure5.gif

Cisco 837 VPN LAN-to-LAN i VPN Client (v4.0.x)

Reading time: 2 – 3 minutes

Aquesta tarda he configurat dos Cisco 837 per dos clients, un per fer un enllaç LAN2LAN entre Alacant i Vic, i un altre per fer enllaçar una oficina amb els seus usuaris en iterància, que connectaran amb VPNClient des de qualsevol lloc. Doncs bé no faré el típic mini-manual o cookbook per explicar com ho he fet. Ja que Cisco si algo té ben parit és la documentació tècnica que es pot obtenir a través del CCO (Cisco Connection Online). També s’ha de dir que si no teniu uns coneixements mínims e Cisco o un CCNA, almenys, no és tasca fàcil barallar-se de bones a primeres amb la CLI de Cisco.

cisco837.jpg

Pels que no conegueu els routers 837 de Cisco, són els que últimament més es monten ja que són routers ADSL i amb una gran diversitat de IOS per instal·lar, a més suporten moltes funcions de seguretat: VPNs, firewall, ssh, etc. Doncs bé a continuació us poso els links del CCO d’on he tret la informació per configurar el router i al costat un link amb el pdf en local, per la gent que no tingui accés al CCO de Cisco.

OpenVPN roadwarrior over PROXY

Reading time: 2 – 4 minutes

Com ja sabeu fa uns dies em vaig montar un sistema per poder anar pel món amb el portàtil i connectar-me a la xarxa interna de casa, des de qualsevol lloc. Doncs bé hi ha llocs on no tenim una sortida a internet sinó que aquesta és a través d’un proxy, a vegades fins hi tot autenticat. Fins hi tot ens podem trobar en que no tenim ni DNS a la xarxa en la que estem sinó que tot es fa a través de l’HTTP PROXY.

Doncs bé quan ens ho posen tan difícil també podem usar l’OpenVPN per connectar a casa i fins hi tot navegar per internet a través de la xarxa de casa disfrutant de tots els serveis de la xarxa i no amb els ports ‘capats’ com ens obliga el proxy/firewall de torn. L’únic que cal és modificar la configuració del client d’OpenVPN per poder sortir a través del proxy de torn contra el port del servidor de l’OpenVPN que tenim a casa.

Al document on explicava com connectar-nos per VPN a casa, sent nosaltres roadwarriors, vaig posar el servidor al port 443/TCP. Doncs ara veieu el motiu, la idea és que si el servidor esta en aquest port el servidor proxy ens deixa passar a través seu per connectar-hi pensant que on connecteu és una web segura (HTTPs), al accedir a un servei xifrat el proxy/firewall no poden inspeccionar els paquets que passen a través seu i podem establir la VPN usant com a protcol de transport el SSL.

A continuació encomptes d’ensenyar-vos una connexió real amb un proxy d’una empresa el que faig és usar un proxy públic dels que hi ha per poder navegar de forma anònima per internet. Si en voleu una llista la podeu trobar a: llista pública de proxies. Concretament per la configuració de prova jo he usat el 194.80.193.161 pel port 8082. Així doncs al fitxer de configuració del client he afegit:

http-proxy 194.80.193.161 8082

Per disimular encara més el rastre de la vostre VPN podeu usar les següents comandes i el firewall en qüestió, ni tan sols olorarà que monteu una VPN:

http-proxy-option VERSION 1.1
http-proxy-option AGENT "compatible; MSIE 6.0; Windows NT 5.1"

Molt senzill,oi? si el proxy és autenticat podeu consultar el man openvpn les comandes per enviar l’usuari i el password. A mi de moment no m’ha calgut.

Apa doncs ja poden anar posant servidors proxy i firewalls que nosaltres ens les continuarem empescant per sortir a internet com deu mana i no pas reduint internet al servei de web. Que tot i ser dels més usats sempre és limitadíssim.

Consum d’ampla de banda de l’OpenVPN

Reading time: 1 – 2 minutes

Com que he de montar algunes VPNs amb GPRS/UMTS i l’OpenVPN entre servidors i clients linux, doncs m’he decidit a fer una prova per fer les estimacions de costos d’aquests enllaços. Així doncs m’he ajudat de l’eina mesure feta pel pancake. Una d’aquelles petites meravelles que ens brinda el GPL. Doncs bé amb el codi que veieu he extret el següent calcul:

time ./mesure -i eth0 -K -p "tcp and port 443"
168
real    60m30.922s
user    0m0.004s
sys     0m0.004s

Com podeu veure he llençat el mesure durant 60min i 30s amb 922ms, el tràfic que s’ha cursat pel port 443 tcp que és on he aixecat i he parat l’VPN durant aquest temps ha estat de 168KBytes. Aquest tràfic sense que per dintre de la VPN passes cap dada meva, simplement dades del propi openvpn per tal de manterir l’enllaç aixecat.

Una altre dada que us pot interessar és que només per aixecar l’enllaç es consumeixen 16KBytes i per baixar-lo uns 2KBytes. Ara cadascu que tregui les seves propies conclusions sobre si és molt o poc.

OpenVPN roadwarrior (client windows)

Reading time: 4 – 6 minutes

Com us comentava al meu anterior article OpenVPN roadwarrior (server i client linux) també podem tenir un roadwarrior de la nostre VPN funcionant amb windows. Així que us descriuré breument com configurar aquest client configuració que és pràcticament idèntica a la del client linux.

El primer que hem de fer és clar, és baixar el paquet de l’openVPN per windows, el podeu trobar a la web de l’openVPN GUI for Windows. Després de descarregar-lo el podeu instal·lar on més us agradi un cop fet això comença la part interessant.

NOTA: si llegiu la documentació de l’openVPN per windows veureu que no he col·locat els fitxers de configuració a les direccions on ell espera trobar-les. I tampoc uso la propietat de servei de windows que pot tenir el programa. Però si ho voleu fer com ‘deu mana’ només cal modificar les rutes i treballar amb el servei de windows encomptes del meu script. Però jo he preferit fer-ho així de cara a tenir un control més personal del programa. Odio la transaparència del windows, prefereixo el meu sistema. Tot són gustos.

NOTA II: els mac també tenen un client d’openVPN anomenat Tunnelblick GUI for mac OS X. Però no tinc el gust de disposar d’un mac per provar i explicar-vos com va, us haureu de conformar amb les instruccions de la seva pàgina web.

Certificiat client

Aquesta part és igual que en linux, o sigui, que podeu mirar el post que us comentava més amunt i sabreu com es fa. Un cop tinguem el certificat client i la clau privada, copiem aquests dos fitxers juntament amb el ‘root CA’ a una carpeta de windows. Jo el que he fet és crear-me una carpeta que es diu openvpn a l’escriptori i dins he creat el directori certs, on hi he copiat els tres fitxers.

Configuració del client

Dins de la carpeta openvpn que comentava dins del punt anterior he creat un fitxer de configuració que es diu local.conf amb el següent contingut:

client
verb 1
remote 2.2.2.2 443
dev tun
comp-lzo
nobind
proto tcp-client
ca ./certs/cacert.pem
cert ./certs/vpn-clientwin-cert.pem
key  ./certs/vpn-clientwin-key.pem

Com podeu veure el fitxer és pràcticament identic al de linux, només li he baixat el nivell de debug (verb 1) perquè aquí la sortida de logs es farà per consola i si pugem molt el nivell de debug ens ompla de bassura la consola.

Configuració interficie TAP/Win-32

Després d’instal·lar el paquet d’openvpn per win veureu que teniu una nova interficie de xarxa:

interficie.png

Aquesta interficie com podeu veure l’he renombra i l’he anomenat tun al fitxer de configuració que heu vist més amunt també uso la interficie tun i no la tap que és el nom del driver de l’interficie. La veritat no sé si hi té molt a veure això però havia tingut alguns problemes al configurar i al final m’ha quedat tal com veieu funciona.

Cal que tinguem la interficie configurada en mode DHCP, per tal de que agafi la IP de túnel automàticament:

configuracio.png

Script de llençament

Finalment el que m’he fet és un petit script (.bat) per llençar la VPN l’he anomenat vpn.bat i el contingut és tan senzill com:

cd "H:\Documents and Settings\Oriol\Escritorio\openvpn"
openvpn --config local.conf

Col·locar-me a la carpeta on hi ha tots els fitxers i després llençar l’openvpn informant-lo del fitxer de configuració que ha d’usar. És importnat indicar la carpeta de treball així el fitxer de configuració com podeu veure usa direccions relatives per referir-se als certificats. Molt més senzill que no pas haver d’escriure el ‘peazo’ directori absolut.

Depuració i proves d’ús

Aquí podeu fer les mateixes proes que amb el linux, també veureu que la interficie tun té el ‘cable de xarxa desconnectat’ fins que no es connecta l’VPN que passa a estar en mode ‘connectat’. Si feu un ipconfig /all des de la consola del windows també podreu veure la interficie tun amb la IP de túnel un cop connectada i si feu un route print les rutes estàtiques que li ha assignat el servidor de la VPN al crear-se la mateixa. Recordeu que això el servidor ho feia a través de la comanda push.

OpenVPN roadwarrior (server i client linux)

Reading time: 7 – 12 minutes

Doncs ja fa temps que sóc usuari de l’OpenVPN per mi un dels millors softwares per montar VPNs i pel que sembla no sóc l’únic, ja que a newsforge també es pot llegir un article que defensa el mateix: SSL VPNs and OpenVPN: A lot of lies and a shred of truth. Doncs bé fer un enllaç LAN2LAN ho podeu fer amb molt pocs segons, jo diria que amb menys d’1min. A més permet tan montar-les per tcp, com per udp, a més de passar per sobre de HTTP proxies d’això ja en parlaré en un altre article.

El que vull explicar aquí és com he configurat l’OpenVPN per poder connectar-me des de qualsevol lloc a la xarxa de casa (i d’altres xarxes que ara no venen al cas). L’autenticació i xifrat de l’enllaç el faré amb SSL/TLS. Així doncs quasi tot el que vaig explicar sobre CAs a l’article: HTTPs, SSL i Certificats en Servidor i Client – Webs privades amb una C.A. ho podrem aplicar aquí.

L’esquema del que anem a montar el podeu veure en el següent gràfic:

Certificats

Així doncs, anem a resumir el tema dels certificats, com que tenim un servidor i un client, hem de generar el certificat pel servidor i pel client, no cal generar el CA, perquè ja en tenim un de l’article comentat. Així que ens col·loquem al directori ~/CA i creem els 3 fitxers tal i com indica l’article al que ens referim.

Ara tindrem els 3 fitxers de rigor:

newreq.pem -> petició de certificat que fem al CA
newcert.pem -> el certificat que ens torna el CA, després de signar la nostre petició de certificat
newkey.pem -> la clau privada del nostre certificat

Només afegir un comentari: mentre creem els fitxers comentats ens demani el ‘Common Name’ podeu posar algún nom representatiu ara no estem lligats a un nom de domini com en l’article en el que ens basem per crear els certificats. Per tal d’organitzar-nos el que farem és renombrar aquests fitxers amb els següents noms:

newcert.pem -> vpn-server-cert.pem
newkey.pem -> vpn-server-key.pem

La petició de certificat la podem borrar si volem. No la farem servir. Per completar els fitxers que ens fan falta per montar el servidor només cal crear el fitxer de paràmetres Diffie-Hellman. Escencialment ens ajudarà a establir VPNs segures en canals no segurs mentre s’intercanvien les claus simètriques que s’usaran per fer la VPN. Recordeu que les claus assimètriques (certificats que usem) només es fan servir com a mitja per establir un canal segur per on intercanviar una clau simètrica molt més ràpida de xifrar/desxifrar pels extrems que ens permetran mantenir un canal segur i el més ràpid possible.

Bé doncs creem aquest fitxer de paràmetres Diffie-Hellman: (dh1024.pem)

openssl dhparam -out dh1024.pem 1024

Jo només l’he fet de 1024bits però el podeu fer tan segur com volgueu 2048, 4096 o fins on tingueu ganes d’arribar. Jo he preferit no carregar els sistemes amb claus inútilment llargues pel tipus de seguretat que necessito. Bé doncs, ara només cal que creem els certificats del client tal i com hem creat els del servidor i com sempre us recomano canviar-li els noms al nou certificat, jo faré els següents canvis de nom:

newcert.pem -> vpn-client-cert.pem
newkey.pem -> vpn-client-key.pem

NOTA: Si voleu tenir més d’un client que es connecti de forma simultànea a l’VPN heu de crear un certificat per cada client.

Fitxer de configuració del servidor OpenVPN

Ara que ja tenim els certificats apunt els copio al servidor al directori /etc/openvpn/roadwarrior/certs. Anem a veure que hem de fer per preparar el fitxer de configuració, que en Gentoo va a /etc/openvpn/roadwarrior, al fitxer l’anomeno local.conf:

verb 5
status /var/log/openvpn-status.log
user nobody
group nogroup
persist-key
persist-tun
local 2.2.2.2
port 443
proto tcp-server
dev tun
comp-lzo
ca   /etc/openvpn/roadwarrior/certs/cacert.pem
cert /etc/openvpn/roadwarrior/certs/vpn-server-cert.pem
key  /etc/openvpn/roadwarrior/certs/vpn-server-key.pem
dh   /etc/openvpn/roadwarrior/certs/dh1024.pem
server 10.0.1.0 255.255.255.252
keepalive 10 120
push "route 10.0.0.0 255.255.255.0"

Si anem per ordre, a l’inici l’únic que fem és dir-li el nivell de debug que volem que es guardi i a quin fitxer. Després definim que el procés openvpn que tindrem corrent al sistema no tingui privilegis sobre el linux (nobody:nogroup). La part on comencem a tenir informació interessant és on ens indica amb la comanda local quina és la IP del firewall que esta escoltant peticions i ens diu que ho fa pel port 443 i sobre protocol TCP. Pot semblar una mica raro que escolti en un port pensat per ser usat per HTTPs però tinc els meus motius, de totes formes si no us agrada el port el canvieu. En un altre article que parlaré de com montar VPNs sobre HTTP proxies explicaré el perquè del port 443. Després li diem amb quina interficie de túnel treballarem i que usarem compresió per les dades que hi passin.

Arribem a la part de certificats on com veieu usem tots els fitxers que em creat anteriorment i el cacert.perm que és el certificat del ‘root CA’ que varem crear a l’article al que em refereixo tota l’estona. A les últimes tres línies el més destacat és que li diem de quin rang han de ser les IPs de la interficie de túnel, això ho fem amb la comanda server i després amb la comanda push llencem una ruta estàtica que li dirà al client com arribar a la LAN que tenim connectada a l’interior de firewall.

Si ara llenço el dimoni de l’OpenVPN (/etc/init.d/openvpn start) puc veure com el port 443 de la interficie pública esta escoltant les connexions que li arriben això ho podeu mirar amb un netstat -lpn.

Configuració del client

Primer comentar que el fitxer de configuració estarà guardat a /etc/openvpn/casa/ amb el nom local.conf i els certificats de client els copiem a /etc/openvpn/casa/certs/, anem a donar un cop d’ull al fitxer de configuració:

client
verb 5
remote 2.2.2.2 443
dev tun
comp-lzo
nobind
proto tcp-client
ca /etc/openvpn/casa/certs/cacert.pem
cert /etc/openvpn/casa/certs/vpn-client-cert.pem
key  /etc/openvpn/casa/certs/vpn-client-key.pem

Com podeu comprovar la configuració del client és mínima, la part més important és la que amb la comanda remote indiquem quina és la IP pública i el port on hi ha el servei que ens ofereix la VPN. Fixeu-vos amb la comanda nobind on li diem que el client no ha d’estar escoltant a cap port, només obrir una connexió contra el servidor. Indiquem quins són els fitxers a usar pel certificat de client i el certificat de la ‘root CA’ i llestos, ja tenim el client a punt.

Per llençar el client, podeu igual que al servidor llençar la comanda /etc/init.d/openvpn start.

TCP vs UDP

Com podeu veure he montat la VPN sobre TCP però també es pot montar sobre UDP, és tan senzill com canviar la comanda proto tcp-server del servidor i proto tcp-client del client, per la comanda proto udp. Per traspassar alguns firewalls i per montar VPNs darrera de NATs sense redirigir ports és molt útil poder-la montar en NAT, ja us explicaré com es pot fer tot això amb un altre article.

Com ja he comentat abans si no us agrada el port 443, també es pot canviar pel que volgueu, no sé si a nivell de IANA es recomana usar algún port en concret per aquest tipus d’VPNs.

Depurar

Per veure quins són els missatges que treu el servidor ho podeu fer al fitxer que indica el propi fitxer de configuració, o sigui, /var/log/openvpn-status.log. Per veure els missatges del client podeu mirar el vostre fitxer de log’s general del sistema sovint: /etc/log/messages.

Si alguna cosa no us funciona us recomano que repasseu tots els passos comentats i que mireu els enllaços de les pàgines en que jo m’he basat per fer la meva configuració.

La prova

Com és lògic la prova de foc està en des del client fer un ping a una IP privada de la intranet de darrera el firewall, per exemple, si 10.0.0.1 és un server de la xarxa 10.0.0.0/24 doncs des del portatil fent ping 10.0.0.1 aquest ens hauria de tornar i si fem un traceroute -n 10.0.0.1 només hauria d’haver-hi dos salts, el firewall i el server destí. Perquè tota la comunicació va per dins el túnel i els salts que es fan per internet són transparents des de dintre el túnel.

Enllaços

Webs d’on he tret la informació per montar tot això:

Scroll to Top