Guneen arteko VPN ala urruneko sarbidea: zer elkartzen duen bakoitzak
Batek ateak elkartzen ditu, besteak gailuak. Konparatu trafiko-hautatzaileak ibilbideekin, planifikatu helbideratzea eta gero probatu birbidalketa eta politika benetako ostalari batetik.
Bi diseinuei VPN deitzen zaie eta arazo desberdinak konpontzen dituzte. Guneen arteko tunelak bi ate elkartzen ditu, beraz haien atzeko ostalari bakoitzak beste aldeko baimendutako helbideak har ditzake ezer instalatu gabe. Urruneko sarbideko tunelak gailu indibidualak sare batekin elkartzen ditu, bezero bat aldi berean. Konparazioa garrantzitsua da, hedapen-errore gehienak diseinu bat konfiguratzean bestearen jokaera espero delako sortzen baitira, eta sintoma normalean tunelak benetan iritsi duen zerbitzu bateko itxaronaldia agortzea da.
Bi diseinu, bi muga
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
Inongo diseinuk ez du LAN difusio-domeinua zabaltzen. Urruneko aldeko gailuak ez dira tokiko aurkikuntza-zerrendan agertzen, eta hala espero izatea baztertu beharreko lehen hipotesia da. Nahita argitaratzen dituzun DNS izen pribatuak edozein aurkikuntza-protokolo baino aurreikustekoagoak dira eta hornitzaile-aldaketari aurre egiten diote.
Hartu 10.10.0.0/24 gune batean eta 10.20.0.0/24 bestean. A ateak ibilbide edo trafiko-hautatzaile bat behar du 10.20.0.0/24 aurrizkia tunelera bidaltzen duena, eta B ateak haren ispilu-irudia behar du. Ondoren, bi aldeetako ostalariek ohiko IP konektibitatea erabiltzen dute eta ez dute inoiz tunel bat badenik jakiten. Ikusezintasun hori da ezaugarria, eta horregatik huts egiteak sare-errore arrunt gisa agertzen dira, tunel-errore gisa izan beharrean.
Politikan oinarritua eta ibilbidean oinarritua ez dira tunel bera
Politikan oinarritutako IPsec hedapenean, negoziatutako trafiko-hautatzaileek zehazten dute zein iturri eta helburu bikote dauden babestuta. Ate baten atzean azpisare berri bat agertzen bada eta hautatzailerik ez badu estaltzen, tunelak martxan jarraitzen du eta azpisare berria ez da eramaten. Ibilbidean oinarritutako diseinuan, interfaze batek hartzen du trafikoa eta ibilbide-taulak erabakitzen du, eta horrek aurrizki bat gehitzea ibilbide-aldaketa bihurtzen du, tunelaren bernegoziazioa izan beharrean.
StrongSwanek bi ikuspegiak zuzenean erakusten ditu, eta biak batera irakurtzea da benetan zein eredu hedatu duzun jakiteko bidea.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'
Garrantzitsua zaizun aurrizkia alde batera uzten duen hautatzaile-zerrenda batek hutsa azaltzen du pakete-harrapaketarik gabe, eta interfaze okerrera seinalatzen duen ibilbide batek itzulera-bideko ispilu-hutsa azaltzen du. Irakurri biak ezer berriro negoziatu aurretik, gako-berritze batek ez baitu inoiz konfiguratu ez duzun hautatzailerik gehituko.
Planifikatu helbideratzea tunela baino lehen
Gainjartzen diren barrutiak konfigurazioarekin konpondu ezin den diseinu-errorea dira. Bi guneek 192.168.1.0/24 erabiltzen badute, 192.168.1.50 behar duen ostalariak bi hautagai ditu eta ez du hautatzeko modurik. Tunelak autentifikatu egingo da, segurtasun-elkarteak ezarriko dira, eta ibilbide-erabakia okerra edo anbiguoa izango da hala ere.
Aukeratu hiru aukera zintzoetatik bat: gune bat berriz zenbakitzea, gainjartzen den barrutia atean itzultzea alde bakoitzak aurrizki desberdin bat ikus dezan, edo ostalari horien ibilbide zuzenari uko egitea eta zerbitzua beste modu batera argitaratzea. Bakoitzak kostua du, eta lehena da normalean merkeena bi urteko horizontean. Erabaki tunela existitu aurretik, gero aldaketak helbide zaharra duen gailu guztiei eragingo baitie.
Konpondu MTU kontua goiz ere. Tunelak karga erabilgarria murrizten du, eta zatiketaren mende dagoen diseinuak bestelako jokaera du MSS ateetan finkatzen duenak baino.
Birbidalketa eta politika tunelatik kanpo daude
Ateak prest egon behar du paketeak tunel-interfazearen eta LAN-interfazearen artean birbidaltzeko, eta bi norabideek zerbitzua baimenduko duen politika behar dute. Linuxen bi ezarpen bereizi dira, gainera birbidalitako fluxua oro har baimenduta dagoen erabakitzen duten suebaki-arauak.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT
Harrera-ostalariak hirugarren geruza gehitzen du: bere suebakiak urruneko azpisareko bezero bat onartu behar du oraindik. Bere tokiko /24 soilik baimentzen duen fitxategi-zerbitzari batek 10.20.0.7tik birbidalitako trafikoa baztertuko du, tunelak zenbat eta osasuntsuago egin, eta bazterketa hori ibilbide-hutsegite gisa irakurtzea erraza da.
Probatu ostalari batetik, ez atetik
Ateak berak bidalitako ping batek jatorrizko helbide eta politika desberdinak jarrai ditzake birbidalitako erabiltzaile-trafikoak baino. Horrek proba ahula bihurtzen du eta, batzuetan, engainagarria: aplikazioa huts egiten duenean lortzen du arrakasta, edo aplikazioa dabilenean huts egiten du.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null
Erabili benetako ostalari bat, benetako jatorrizko helbidea eta aplikazioak erabiltzen duen benetako protokoloa. Gero irakurri itzulera-bidea bereizita, itzulera-ibilbiderik gabeko aurrera-norabide batek itxaronaldia agortua sortzen baitu blokeatutako zerbitzu baten itxura berbera duena.
Aukeratu diseinua erantzuten ari zaren galderaren arabera: sareak elkartzen ari zara, edo gailuak onartzen? Gainerako guztia, zein hornitzaile konfiguratzen duzun barne, erantzun horretatik dator.