Barneko bi suebaki, transitatu-segmentu pribatu bat eta LAN bakoitzean hainbat ostalarik bestearekin hitz egiteko eskaera. Erreflexua VPN bat jasotzea edo bigarren NAT geruza gehitzea da, eta bi erreflexuek arazoak merezi baino gehiago balio dute. Bideratze arrunta nahikoa da hiru baldintza betetzen direnean: helbide-barrutiek ez dute gainjartzen, bi aldeek beste LAN-era trafikoa itzul dezakete eta transitatu-segmentua datuetarako nahikoa fidagarria da. Egiaztatu hiru horiek ezer diseinatu aurretik, bakoitzak erantzuna aldatzen baitu.

Diseinua erabakitzen duten hiru baldintza

Lehen baldintza helbide-eremua da. Bi LAN-ek RFC 1918 bloke bera erabiltzen badute, bideratzeak ezin ditu bereizi eta itzulpena saihestezina bihurtzen da, hautazkoa izan beharrean. Bigarrena itzulera-bidea da: A-tik B-rako bidea erabilgarria da B-k A-ren LAN-era nola iritsi ere badakienean baino ez, eta ezagutza asimetrikoa da diseinu bideratuak erantzunak isilka botatzeko arrazoi ohikoena.

Hirugarrena konfiantza da. Bideratzeak paketeak mugitzen ditu; ez ditu babesten. Eraikin baten barneko transitatu-segmentu pribatua beste kontu bat da hornitzaile bati egindako entrega edo campuseko bizkarrezur partekatua zeharkatzen duen esteka batekin alderatuta. Segmentua fidagarria ez bada, erantzuna bi suebakien arteko tunela da, eta beheko bideratze-plana oraindik balio du haren barnean.

Hirurek norabide berean seinalatzen dutenean soilik irabazten du diseinu sinpleak. Horietako bat huts egiten duenean, zuzendu baldintza hori modu esplizituan itzulpenarekin estali beharrean, NAT-ek hutsa ezkutatzen baitu, ez du konpontzen.

Eraiki bide-plana transitatu-sarean

Eman suebaki bakoitzari helbide bat segmentu partekatuan eta gehitu bide zehatz bat urruneko LAN bakoitzeko. Ez da ezer gehiago mugitu behar lehendik dagoen konfigurazioan, eta bereziki interneteko bide lehenetsiak leku berean egon behar du. Bide lehenetsia pareko suebakiagatik ordezkatzeak erlaziorik gabeko helmuga guztiak transitatuaren bidez bidaliko lituzke, eta hori eskatutakoa baino aldaketa askoz handiagoa da. pfSense-ren bideratze estatikoari buruzko dokumentazioak plataforma horretarako bide-gehi-ataka eredu bera deskribatzen du, eta baliokidea den kontrola badago zuk benetan exekutatzen duzun edozein suebakitan.

FirewallRemote LANNext hop on the transit
A10.40.0.0/24192.0.2.20
B10.30.0.0/24192.0.2.10

Suebaki A-k 10.30.0.0/24 zerbitzatzen du eta suebaki B-k 10.40.0.0/24, bi transitatu-helbideak 192.0.2.0/24-n daudelarik. LAN ostalari bakoitzak bere suebaki lokala gordetzen du ataka gisa, beraz estatu berri bakarra alde bakoitzeko bide bat da. Linux-en oinarritutako suebaki batean plan bera horrela ikusten da, eta birbidaltzea gaituta egon behar da, bestela bidea ebatziko da paketea baztertzen den bitartean.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Bereizi iragazketa itzulpenetik

Bideratzea eta politika kontrol desberdinak dira, eta bigarrenean huts egiten dute benetan diseinu bideratu gehienek. Baimendu iturri, helmuga eta zerbitzu zehatzak paketeek benetan zeharkatzen duten sarrera-mugan, eta gogoratu WAN bezalako interfaze-etiketa izen bat dela, ez konfiantzari buruzko adierazpena. Trafiko pribatua daraman transitatu-ataka batek helbide pribatuen blokeoa gaituta izan dezake oraindik lehenespenez.

Gero begiratu irteerako itzulpenari, NAT-ik gertatzen ez dela ondorioztatu aurretik. Irteerako arau automatikoek inoiz itzultzeko pentsatu ez zen trafikoa berridatz dezakete, eta horrek beste aldeak bere politika eta erregistroetarako behar dituen iturburu-helbideak suntsitzen ditu. Egiaztatu hautatutako fluxuek jatorrizko helbideak gordetzen dituztela, eta utzi interneteko itzulpen-arauak bakean oraindik behar dituen trafikoarentzat.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

NAT egiazko erantzuna denean

Itzulpenak bere lekua irabazten du helbide-barrutiek benetan gainjartzen direnean eta berrenumeratzea erabilgarri ez dagoenean, edo politikak alde batek azpisare bat baino helbide bakarra ikustea eskatzen duenean. Kasu horietan, nahita egindako bat-bateko edo ataka-mugatutako mapaketa ondorio ezagunak dituen diseinu-erabakia da, ez irtenbide behin-behinekoa.

Ozen esan beharreko ondorioa da beste aldeak ezin dituela jada iturri indibidualak ikusi edo iragazi. Erregistroak itzultzen duen helbidera jaisten dira, ostalari bakoitzeko politika funtzionatzeari uzten dio, eta arazoak konpontzea une jakin batean fluxu bat zein barne-ostalarik zuen ehizatzea bihurtzen da. Horietako ezerk ez badu axola dagokion trafikoarentzat, NAT ondo dago.

Transitatuak berak gaizki pentsatutako ustea denean

Segmentu partekatuak hornitzaile bat, etengailu-ehun partekatu bat edo beste alderdi batek trafikoa irakur lezakeen edozein bide zeharkatzen badu, bideratze hutsa ez da erantzun osoa. Bi suebakien arteko tunelak konfidentzialtasuna eta parekidearen autentifikazioa ematen dizkizu, eta haren barneko bide-taula transitaturan idatziko zenukeen taula bera da.

Erabaki hori lehen ataleko konfiantza-galderatik, ez VPN-ak seguruagoak direlako ohituratik. Dagoeneko pribatua den segmentu baten gaineko tunelak ustiapen-kostua eta hutsegite-modu bat gehitzen ditu irabazirik gabe; transitatu ez-fidagarri baten gaineko bideratzeak, berriz, konfidentzialtasuna ordaindu ezin duzun sinpletasunagatik trukatzen du. Idatzi hiru baldintzetatik zeinek bultzatu zuen hautua, eta hurrengo ingeniariak ez du berriro eztabaidatu beharko.

Erlazionatutako artikuluak