Cloud 9 – VPN-yhteydet
Cloud 9-palvelussa VPN-yhteydet ovat sallittuja ja niitä ei ole erikseen estetty. VPN-yhteyden voi luoda asentamalla instanssiin tai instansseihin tarvittava VPN-ohjelmisto, tai asentaa erikseen appliance-paketin hoitamaan VPN-yhteyksiä. Esimerkissämme teemme ohjelmallisen VPN-yhteyden DMZ-palvelimen läpi (bastion host). Muut instanssit ovat ainoastaan LAN-verkossa.
HUOM! VPN-yhteyksissä on tärkeää sallia instanssin reitittämä liikenne ulkopuolisista verkoista, koska palvelussa on port security (antispoof) ominaisuus päällä. Bastion host-instanssi ei voi välittää liikennettä jos sitä ei erikseen sallita.
Luodaan esimerkkiä varten kaksi verkkoa, DMZ (10.0.0.0/24) ja LAN (10.1.0.0/24)
Asennetaan Cloud 9:ään Bastion host –instanssi Centos 7 tiny-flavorillä, tälle liitäntä kumpaankin verkkoon. Varataan Floating IP ja sidotaan se instanssin DMZ-porttiin.
Haetaan consolesta palvelimelle Openstack RC-tiedosto, tallennetaan tiedostoon pysyvästi OpenStack-salasana, ja ajetaan tiedosto (käsky ”source tiedosto”)
Asennetaan instanssiin Openstackin työkalut (RDO), pakettien nimet python-PROJECTclient (missä PROJECT on nova, neutron, cinder, swift yms)
Kun python-neutronclient on asennettu, käsketään
neutron port-list
Tuloste on jotakuinkin kuvanmukainen, ja tässä tapauksessa etsimme LAN-verkon porttia (esimerkissä IP 10.0.0.4, eli portin id on cbbb1c32-a516-4a11-a5ea-780e733dfc11)
Sallitaan tältä portilta liikennöinti LAN-verkosta ulospäin käyttäen mitä tahansa IP-osoitteita:
neutron port-update cbbb1c32-a516-4a11-a5ea-780e733dcf11 –allowed-address-pairs type=dict list=true ip_address=0.0.0.0/0
ip_address-tietueeseen voi toki laittaa tiukemman rajoituksen, jos on tiedossa että VPN:n läpi tulee tiedossa oleva rajatumpi verkko.
Nyt bastion host voi välittää liikennettä VPN-verkon ja LAN-verkon välillä.
VPN/NAT
Jos haluaa kaiken liikenteen ohjata oman NAT/VPN –instanssin läpi, reitittävällä instanssilla pitää linuxissa erikseen mahdollistaa tämä:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -o eth0 -A POSTROUTING -j MASQUERADE
iptables -t nat -o eth1 -A POSTROUTING -j MASQUERADE
Tämän jälkeen muut instanssit voivat käyttää tätä instanssia oletusyhdyskäytävänä, ja kyseisen LAN-verkon asetuksissa voi määritellä instanssin olemaan default gateway. Näin oikea gateway tulee automaattisesti.
HUOM! Älä määrittele MASQUERADE-sääntöä loopback-kortille (lo), tämä saattaa häiritä palvelimen sisäistä toimintaa. Lisäksi FORWARD-taulussa ei pidä estää liikennettä jos instanssi toimii reitittimenä / NAT-yhdyskäytävänä.
DHCP ja staattiset reitit
Jos halutaan että instansseilla tietty verkko reitittyy oletusyhdyskäytävän sijasta tiettyyn osoitteeseen (esim VPN-instanssille), tämän voi toteuttaa suoraan DHCP-ominaisuuksissa. Networks -> LAN -> Edit Subnet -> Next -> Host routes. Syntaksi on verkko/maski pilkku gateway (esim: 10.2.0.0/24,10.1.0.1). Tässä tapauksessa 10.1.0.1 on bastion hostin LAN-portin osoite.
VPN-ohjelmiston valinta
Jos tarve on vain kahden verkon yhdistäminen ja kummankin verkon rajalla on Linux-instanssi, VPN-yhteytenä voi käyttää esim OpenVPN SSL/TLS-yhteyttä:
http://openvpn.net/
Mikäli toisessa päässä on erillinen VPN-palomuuri tai -reititin, esim IPSec-yhteydet onnistuvat StrongSwan –ohjelmalla:
https://www.strongswan.org/
Lisäksi PPTP-pohjaisen yhteyden saa rakennettua Linuxiin melko helposti mutta emme suosittele sen käyttämistä.
STRONGSWAN-OHJE (IPSEC)
Esimerkkiä varten meillä on kaksi /24 verkkoa, DMZ ja LAN. CentOS 7-palvelimellamme on kaksi porttia:
DMZ: 10.0.0.1
LAN: 10.0.1.1
Testipalvelimella on myös Floating IP 77.86.179.250 joka on kiinnitetty DMZ-porttiin.
Toisessa kaupungissa sijaitsee VPN-palomuurireititin McAfee SG560 julkisessa IP-osoitteessa 9.9.9.9, ja tämän laitteen takana on toimiston LAN-verkko 10.10.0.0/24
Pilven Security Groupeissa palvelimelle pitää sallia IPSec-yhteyksiin tarvittavat portit ja protokollat VPN-laitteelta (UDP 500, UDP 4500, IP-protokolla 50 eli ESP)
VPN-palomuurin päässä IPSec-asetukset ovat:
Phase 1: IKEv1 3DES-SHA-DH5 (MODP1536)
Phase 2: 3DES-SHA-DH5 (MODP1536, PFS päällä)
PreShared key: testiavain123
VPN-yhteydessä Pilven pään StrongSwan on loogisesti ”left” ja vastapään VPN-laite ”right”, joten yhteyspisteet nimetään kummassakin päässä ID-tiedolla ”@left” ja ”@right”. ID-tietojen on täsmättävä, muuten yhteys ei muodostu.
Asennetaan StrongSwan testipalvelimeen:
yum install strongswan strongswan-libipsec
Asennuksen jälkeen kirjoitetaan /etc/strongswan/ hakemistoon seuraavat tiedostot:
ipsec.conf:
config setup conn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 authby=secret keyexchange=ikev1 mobike=no conn net-net ike=3des-sha-modp1536 esp=3des-sha-modp1536 left=10.0.0.1 leftsubnet=10.0.1.0/24 leftid=@left leftfirewall=yes right=9.9.9.9 rightsubnet=10.10.0.0/24 rightid=@right auto=add
ipsec.secrets:
@left @right : PSK testiavain123
Muihin tiedostoihin ei tarvitse koskea.
Sitten käsketään:
strongswan start
strongswan up net-net
Yhteys muodostuu laitteiden välillä ja liikenne LAN-verkkojen välillä toimii kunhan ”neutron port-update” käskyllä liikenne LAN-portista on sallittu.
Jos haluat yhteyden nousevan palvelimen käynnistymisen yhteydessä, pitää strongswan laittaa bootissa käynnistymään käskyllä
systemctl enable strongswan.service
ja vaihtaa ipsec.conf-tiedostosta “auto=add” muotoon “auto=start”.
Käsky strongswan up net-net antaa seuraavankaltaisen tulosteen:
# strongswan up net-net initiating Main Mode IKE_SA net-net[1] to 9.9.9.9 generating ID_PROT request 0 [ SA V V V V ] sending packet: from 10.0.0.1[500] to 9.9.9.9[500] (212 bytes) received packet: from 9.9.9.9[500] to 10.0.0.1[500] (136 bytes) parsed ID_PROT response 0 [ SA V V V ] received unknown vendor ID: 4f:45:49:70:42:4c:6d:5f:4e:5b:6f:59 received DPD vendor ID received NAT-T (RFC 3947) vendor ID generating ID_PROT request 0 [ KE No NAT-D NAT-D ] sending packet: from 10.0.0.1[500] to 9.9.9.9[500] (308 bytes) received packet: from 9.9.9.9[500] to 10.0.0.1[500] (292 bytes) parsed ID_PROT response 0 [ KE No NAT-D NAT-D ] local host is behind NAT, sending keep alives generating ID_PROT request 0 [ ID HASH ] sending packet: from 10.0.0.1[4500] to 9.9.9.9[4500] (68 bytes) received packet: from 9.9.9.9[4500] to 10.0.0.1[4500] (68 bytes) parsed ID_PROT response 0 [ ID HASH ] IKE_SA net-net[1] established between 10.0.0.1[left]...9.9.9.9[right] scheduling reauthentication in 3329s maximum IKE_SA lifetime 3509s generating QUICK_MODE request 208874606 [ HASH SA No KE ID ID ] sending packet: from 10.0.0.1[4500] to 9.9.9.9[4500] (372 bytes) received packet: from 9.9.9.9[4500] to 10.0.0.1[4500] (356 bytes) parsed QUICK_MODE response 208874606 [ HASH SA No KE ID ID ] CHILD_SA net-net{1} established with SPIs 67d15f15_i ec25c466_o and TS 10.0.1.0/24 === 10.10.0.0/24generating QUICK_MODE request 208874606 [ HASH ] sending packet: from 10.0.0.1[4500] to 9.9.9.9[4500] (60 bytes) connection 'net-net' established successfully