Tunel baten bidez urrutiko /24 batera iristea: NETMAP, DNAT edo bidea?
Mapatu prefijo oso bat NETMAP-ekin, gehitu DNAT arauak host bakoitzeko edo bideratu benetako barrutia, eta erabaki urrutiko aldeak zer ikusi behar duen eta nork has dezakeen trafikoa.
Tunel baten amaieraren atzean dagoen azpisare batera hiru eratan irits zaitezke, eta minutuko datu-bilketa batek normalean bi baztertzen ditu. Datuak hauek dira: han dauden zerbitzariek erabiltzaileak bereizi behar dituzten, hango norbaitek zure barrutira inoiz deituko duen, eta nori dagokion urrutiko muturreko bideratzailea editatzeko baimena. Hiru horiei erantzun eta diseinuak bere kabuz egingo du aukera. Gainerakoak suposatzen du zu zarela muturra kudeatzen duena eta haren suebakia edita dezakezula.
Hiru aukera, eta zer aldatzen duen bakoitzak benetan
Prefijo-mapaketak, host bakoitzeko DNAT-ek eta bideratutako prefijo batek bi barruti berberen artean mugitzen dituzte paketeak, baina gauza desberdinak aldatzen dituzte. Mapaketak alias-barruti bat asmatzen du eta helbideak aritmetikoki berridazten ditu hegaldian. Host bakoitzeko arauek ere berridazten dute, baina helmuga bakoitza eskuz izendatzen da. Bideratutako prefijo batek ez du ezer berridazten: paketeek benetako helbideak gordetzen dituzte eta bi muturrek ados jartzen dira helbide horiek non bizi diren.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
Hasi bazterketa urrutiko aldean, murrizketak aldatzeko zailenak han baitaude. Hango zerbitzari batek bezeroen helbideak erregistroetan idazten baditu, baimenduen zerrendaren aurka egiaztatzen baditu edo beste sistema bati ematen badizkio, iturria itzultzeak haren identifikatzaile bakarra suntsitzen du. Urrutiko aldeak ere deitu behar badu, itzulpena erabat baztertuta geratzen da, han inork ez baitaki aliasa badagoenik. Urrutiko aldea eskaerei erantzutera mugatzen denean soilik bihurtzen dira seguru aukera merkeagoak.
Prefijo-bikoteak, eta zergatik tamainek bat etorri behar duten
NETMAP nat taulako jomuga bat da, luzera bereko prefijo bikote baten gainean lan egiten duena. Ez du helbideko taularik barnean: prefijoa kentzen du, host bitak gordetzen ditu eta prefijo berriari atxikitzen dizkio; horregatik /24 bat /24 bati mapatzen zaio eta inoiz ez /25 bati. Posizioak erabakitzen du noranzkoa: PREROUTING-en helmuga-kointzidentzia batek berridazten du nora doan paketea, eta POSTROUTING-en iturri-kointzidentzia batek berridazten du nondik etorri den.
192.168.2.17-ko host bat 10.50.1.17 gisa agertzen zaie zure bezeroei, eta azken okteto ez da apaingarria — zenbaki bera da bi aldeetan. Gehitu bihar 192.168.2.40-n host bat eta haren aliasa 10.50.1.40 izango da, editatzeko araurik gabe.
Bezeroek alias-barrutiarentzat zure makinarantz seinalatzen duen bidea behar dute oraindik, aliasa jada iristen diren azpisare baten barruan ez badago. Pasaguneak ez du aliasmaren biderik behar, helmuga-itzulpena PREROUTING-en exekutatzen baita, bide-bilaketaren aurretik. Birbidaltzea ere aktibatuta egon behar da, bestela kernelak paketea botatzen du berridazketaren ondoren. Beheko hiru komandoak Debian estiloko pasagune bateko ezarpen osoa dira, bezeroak br0-n, aliasa 10.50.1.0/24-n eta tunela tun0-n.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEErantzunak berak aurkitu behar du itzulerako bidea
Helmuga berridazteak paketea non entregatuko den baino ez du erabakitzen. Urrutiko aldeko zerbitzariak irits dezakeen helbide bati erantzun behar dio oraindik, eta hori antolatzeko bi modu daude. Itzuli iturria erantzunak zure makinara itzul daitezen, edo utzi iturria bakean eta eman urrutiko aldeari bezeroen barrutiaren bidea.
Irteeran maskaratzea da biderik laburrena: POSTROUTING-en arau bat eta urrutiko aldeak zure tunelaren helbidea ikusten du, beraz ez du bere biderik behar. Kostua da erabiltzaile guztiak helbide bakarrean biltzen direla eta erabiltzaileko erregistroek zentzua galtzen dutela. Iturria ukitu gabe uzteak informazio hori gordetzen du, baina orduan urrutiko guneak bezeroen barrutiaren erantzunak tunelaren bidez itzuli behar ditu. OpenVPN zerbitzari batean hau bidalitako push "route 10.50.9.0 255.255.255.0" bat da, gehi route 192.168.2.0 255.255.255.0 lerro bat.
Hutsegite garestia bakoitzaren erdia egitea da. Trafikoaren zati bat maskaratzen baduzu urrutiko aldeak beste trafiko batzuetarako itzulerako bidea ere daraman bitartean, erantzunak konexio-arrastoaren sarrera inoiz ikusi ez zen interfaze batera iristen dira. Bezeroak denbora-muga jakinarazten du zerbitzariak zerbitzatutako gisa erregistratu zuen eskabide batentzat. Fluxu baten bi noranzkoek netfilter instantzia beretik igaro behar dute: pasagune bat itzultzen, ez bi suebaki segidan.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nIrakurri sarrera bi noranzkoetan: jatorrizko tuplak zure aliasa gordetzen du helmugan, eta erantzun-tuplak benetako helbidea darama. Erantzun-tupla falta bada, arazoa itzulerako bidea da, ez araua. PREROUTING kontagailuak inoiz mugitu ez badira, paketea ez zen inoiz kako horretara iritsi.
Talkak eta lehenengo exekutatzen den bilaketa
Bi barruti desberdin talka daitezke eta bi hutsegiteek tunel hautsi baten itxura dute, arau txar baten ordez. Asmatzen duzun aliasa bide osoan zehar erabili gabe egon behar da, eta urrutiko aldeko benetako barrutiak ezin du zure sarean jada existitu. Bikoizketak noizean behingo trafikoa sortzen du host okerrean, eta hori zailagoa da diagnostikatzen ukatutako konexio bat baino. Galdetu bideratze-taulari araua gehitu aurretik.
Pasagunean, ip route get 192.168.2.17 tresnari tunelaren gailua izendatu beharko lioke; tokiko zubi batek esan nahi du urrutiko barrutia itzalita dagoela eta nat arauek ez dutela konponduko. Zure sareak 192.168.2.0/24 erabiltzen badu jada, zenbakitu berriro urrutiko gunea, talkaren gainean mapaketa bat pilatu beharrean.
Benetako bezero batetik probatzea, eta gero gordetzea
Proba ezazu aliasa benetan erabiliko duen makinatik, ez pasagunetik, tokian sortutako trafikoak ez baitu inoiz PREROUTING era berean zeharkatzen. Ireki konexio bat aliasdun host batera eta behatu kontagailuak eta conntrack sarrera elkarrekin agertzen diren, gero itxi eta egiaztatu sarrera joaten dela. Sarrera zaharkituak erdi-irekitako konexioa adierazten du, eta horrek normalean esan nahi du erantzuna ez zela inoiz itzuli.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Bi edo hiru konexio zuzenek aritmetika frogatzen dute, baina ez dute ezer esaten iraunkortasunaz edo hurrengo ingeniariari buruz. Gorde arauak abiarazte-prozesuak irakurtzen dituen tokian, eta horrek Debian eta Ubuntu-n iptables-save > /etc/iptables/rules.v4 esan nahi du, netfilter-persistent gaituta. Berrabiaraztean desagertzen den mapaketa bat bat ere ez baino okerragoa da, matxurak ez baitu azken aldaketarik errudun gisa.
Utzi ohar bat arauen alboan: alias-barrutia, benetako barrutia, bikotearen arrazoia eta zein aldek has dezakeen. Ohar horrek diseinua inork ezabatzen ez den arau-meta batetik bereizten du. Geroko galdera ere konpontzen du, urrutiko guneak host bat gehitzen duenean eta inork konfiguratu ez duen helbide batek erantzuten duenean. Oharrak urrutiko aldeak itzulerako bidea behar duela dioen ez bada, hurrengo pertsonak badaki maskaratze-araua kentzeak konektibitatea hautsi egiten duela. Dokumentazioa merkea da hemen; NAT mendekotasuna goizeko hiruretan berriro aurkitzea ez.