Urruneko erabiltzaileek ezin dute bigarren gunea VPN zentroaren bidez iritsi

Urruneko erabiltzaile bat zentrora konektatzen da, zentroaren beraren LANean dagoen fitxategi-zerbitzarira iristen da, eta dena osasuntsu dagoela dirudi. Gero 10.20.0.50 helbidean partekatutako karpeta bat irekitzen du egoitza nagusian, zentroak gune arteko tunel bereizi baten bidez iristen dena, eta denbora-muga gainditzen da. Bi tunelak aktibo daude eta bi kontagailuak igotzen dira, beraz ez dago tunelik hondatuta. Zentroa zeharkatzea hiru bideratze-erabaki dira hiru gailutan, eta tunel batek eraiki zen prefijoak bakarrik garraiatzen ditu. Hau da egiaztatzen dudan ordena, eta urrats bakoitza egia den erakusten duen komandoa.

Pasabideak hiru bilaketa behar ditu, ez tunel bat

Gailu bakoitzak bere prefijo luzeenaren bat-etortzea egiten du eta ahaztu egiten du. Eramangarriak 10.20.0.50 tunelera bidali behar du, bere bideratzaile lokalera beharrean. Zentroak urruneko sarbideko interfazean iritsitako paketea hartu eta gune arteko interfazeari eman behar dio. Egoitza nagusiak erabiltzailearen helbiderako erantzuna tunelaren bidez itzuli behar du. Hiruretako edozeinek huts egiteak berdin ikusten du nabigatzailean: isiltasuna.

Horregatik frogatzen du hain gutxi tunel bakoitza bere aldetik probatzeak. Zentroaren LAN helbideari ping egiteak lehen erabakia lantzen du, eta zentroari egoitza nagusitik ping egiteak hirugarrena. Huts egiten duen paketeak erabiltzaile-poola du iturri eta bigarren gunea helmuga, beraz idatzi prefijo horiek lehenengo. Hemen pool-a 10.80.0.0/24 da, zentroaren LANa 10.10.0.0/24 eta egoitza nagusia 10.20.0.0/24.

Bultzatu urruneko prefijoa urruneko bezeroari

OpenVPN urruneko sarbide-zerbitzari batean bezeroak bideak konektatzean ikasten ditu. Pushik gabe, tunel zatitua duen bezeroak 10.20.0.50 bere atakarik bidaltzen du eta paketea ez da inoiz tunelera sartzen.

push "route 10.20.0.0 255.255.255.0"

Bultzatutako bide bat bezeroa konektatzen denean aplikatzen da, beraz linean jarraitzen duen erabiltzaileak ez du ezer ikusten berriro konektatu arte. Egiaztatu bezeroan: ip route get 10.20.0.50 Linuxen, route print Windowsetan. Irteerak tunelaren interfazea izendatu beharko luke.

Pushak ez dio zentroari laguntzen. Bezeroari bidalitako mezua da, ez da zerbitzariko bidea eta ez da birbidaltzeko baimena, beraz push-lerro perfektua duen zentro batek fluxua jaregiten du jauzi bat geroago. Hori da jendeak pushak huts egin duela ondorioztatzeko ohiko arrazoia.

Eman zentroari benetako irteera-bidea

Zentroak bere hurrengo jauzia behar du egoitza nagusiaren prefijoarentzat. Bideratutako tunel batean gune arteko interfazearen bidezko bide arrunta da, eta komando bakar batek erakusten ditu aukeratutako bidea eta aukeratutako iturria:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Gune arteko hanka bera OpenVPN denean, bidea konfigurazio horretan egon daiteke, parekidearen tunel helbidea atakarik gisa erabilita: route 10.20.0.0 255.255.255.0 172.30.0.2. Atakaria ez da aukerakoa. Utzi kanpoan eta hurrengo jauzia inplementazioaren balio lehenetsira erortzen da, eta hori desberdina da parekide bakarreko bezero baten eta parekide anitzeko zentro baten artean.

Politikan oinarritutako IPsec desberdina da: zentroaren nukleoak paketea bere LAN atakari arruntera bidaltzen du eta politikak irteeran harrapatzen du, beraz tunel-bide batek edo ezer ez du egiten edo trafikoa politikatik kanpo gidatzen du. Begiratu iturria goiko komandoan, zeren 10.10.0.1 poolaren helbidearen ordez nukleoak urruneko aldeak baztertuko duen helbide bat aukeratu duela esan nahi baitu. iroute ere ez da erantzuna; zerbitzariari esaten dio zein bezerok duen azpisare bat bere tunelaren atzean, ez hirugarren gune baterako trafikoa nora bidali.

Hedatu urruneko aldea erabiltzaile-poolera

Egoitza nagusiak zentroaren LANa estaltzen du jada, 10.10.0.0/24. Erabiltzaile-poola bigarren prefijoa da eta hautatzaileetan ere egon behar du, bestela politikak ez du 10.80.0.25 helbideratutako erantzunik estaltzen. Parekide bakoitzak prefijo-multzo pare bera aipatzen du bere aldetik:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Gailu baten local_ts bestearen remote_ts da. Kopiatu zentroaren blokea egoitza nagusira eta pareak alderantziz geratzen dira, beraz child SA ez da inoiz altxatzen.

Zaharragoa den ipsec.conf sintaxiak komaz banatutako leftsubnet erabiltzen du. Abian dagoen segurtasun-elkarteak negoziatu zituen hautatzaileak gordetzen ditu, beraz berrezarri tunela aldaketaren ondoren. 10:00etan aldatutako hautatzaile bat 09:40an altxatutako SA baten aurka probatuta oraindik huts egiten du, konfigurazio-fitxategiak denbora osoan zuzena dirudien arren.

Gero egiaztatu azken jauzia. ip route get 10.80.0.25 urruneko muturrean tunelera seinalatu beharko luke. Zerbitzuak LAN bideratzaile bat erabiltzen badu atakari lehenetsi gisa, bideratzaile horrek ere itzulera-bidea behar du, bestela erantzuna han hiltzen da. tcpdump -ni eth1 host 10.80.0.25 segmentu horretan exekutatzeak erakusten du erantzunak muturra utzi ote zuen.

Baimendu fluxua zentroan

Birbidaltzea gaituta egon behar da eta bidea baimenduta. Mugatu arauak bi prefijoetara, interfazeen artean dena onartu beharrean.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Itzulera-bidearen iragazketa alboan dagoen hutsegite isila da: bi hankak interfaze desberdinetan daudenean, rp_filter=1 erantzuna bota dezake onarpen-arauaren kontagailuak inoiz mugitzen ez den bitartean. Konparatu iptables -vnL FORWARD saiakera baten aurretik eta ondoren. Inoiz gehitzen ez den arau batera ez da iristen, beraz begiratu geruza bat beherago berridatzi beharrean.

Talde batek bakarrik behar badu pasabidea, jarri bidea bezero bakoitzeko fitxategi batean client-config-dir azpian, push globala zabaldu beharrean. Zentroan iturburu-NATak urruneko itzulera-bidearen beharra ere kentzen du, baina erabiltzailearen helbidea ezkutatzen du, beraz urruneko gunearen erregistroek eta helbideetan oinarritutako arauek ez dituzte erabiltzaileak bereizten jarraitzen.

Egiaztatu bezerotik eta gero itzuli alderantzizko ordenan

Probatu TCP ataka bat, ez bakarrik ICMP, ping bat pasa baitaiteke zerbitzua blokeatuta jarraitzen duen bitartean. nc -vz 10.20.0.50 445 eta traceroute -n 10.20.0.50 bezerotik erakusten dute bigarren jauzia zentroaren tunel helbidea den. Zentroan, tcpdump -ni tun0 host 10.20.0.50 eta iragazki bera gune arteko interfazean: eskaera bietan eta erantzunik ez batean ere, arazoa urruneko aldera eramaten du.

Gero probatu blokeatuta egon behar duen zerbait. Poolak inoiz iritsi behar ez duen ostalari batek ere erantzuten badu, pasabidea baino gehiago ireki duzu eta arauak estutu beharko lituzke. Hosto bakoitzari dena birbidaltzen dion zentroak lehen proba gainditzen du eta bigarrenean huts egiten du.

Eduki itzultze-zerrenda bat, lau objektu aldatu baitziren eta hiru erraz ahazten baitira: bultzatutako bidea, zentroaren bidea, hautatzaileak eta suebakiko arauak. Desegin itzazu alderantzizko ordenan, berrezarri SA eta utzi erabiltzaile bati berriro konektatzen. Itzultze partzial batek jada bat ez datorren tunel batera seinalatzen duen bidea uzten du, eta hori zailagoa da irakurtzen jatorrizko isiltasuna baino. OpenVPN 2.6 eskuliburuak dokumentatzen ditu push, route eta iroute zure bertsiorako.