Subnet bera bi muturretan: mapatu urruneko LANa tarte libre batera
Bezeroaren aldeko helbide mapatzeak gainjarritako urruneko LAN bat tarte libre baten pean aurkez dezake, baina bezero batzuek soilik aplikatzen dute eta itzulera-bideak hala ere existitu behar du.
Etxeak eta bulegoak biek 192.168.1.0/24 erabiltzen dute, beraz 192.168.1.1-ra egindako eskaerak bi erantzun posible ditu eta bezeroak bat aukeratzen du galdetu gabe. Lanean ari den bulego-sare bat berrabidatzea ez da ia inoiz ona, eta routerraren helbideak maiz inprimatzaile, kamera eta dokumentazioetan txertatuta egoten dira. Bezeroaren aldeko helbide mapatzeak urruneko sarea tarte libre baten pean aurkez dezake horren ordez, eta host zatia berdin geratu daiteke, 192.168.1.20 10.203.41.20 gisa ager dadin. Kakoa da bezero batzuek soilik implementatzen dutela, eta itzulera-bidearentzat ezer egiten ez duela.
Host beraren bi ikuspegi
Mapatzeak host zatia mantentzen du eta sare zatia soilik aldatzen du. Orduan makina berak bi helbidetan erantzuten du zauden lekuaren arabera. Zutabe biak idaztea ezer konfiguratu aurretik geroago logak eta suebakiaren arauak gaizki irakurtzea saihesten du.
| The application dials | The remote device is |
|---|---|
| 10.203.41.1 | 192.168.1.1 |
| 10.203.41.20 | 192.168.1.20 |
Etxeko gailu lokalek beren 192.168.1.x helbideak gordetzen dituzte, eta hori da ariketaren puntua. Alboko gelako inprimatzailea eskuragarri jarraitzen du, bulegoa talkarik egiten ez duen tarte baten pean agertzen den bitartean.
Argumentuen ordena da trikimailu osoa
Aukerak norabide bat, sare bat eta maskara bat, eta alias bat hartzen ditu: lehenengo sarea bezeroak ikusten duena da, aliasa zerbitzariak ikusten duena. Urruneko atebidearen atzean dauden baliabideentzat, norabidea helmugaren forma da. Bi sareak alderantziz jartzea azken argumentua aliasa deitzen delako da tunela konektatu eta ezer mapatzen ez duen akatsa.
push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"
Ibilbidea da bezeroaren paketeak tarte berrirako tunelera bidaltzen dituena; itzulpenak helmuga berridazten du bidean zehar. 192.168.1.20-tik datorren erantzuna 10.203.41.20-ra berridazten da, bezeroaren socket-a koherente egon dadin. Host bakar batek modu berean funtzionatzen du luzera osoko maskara batekin, betiere ibilbideak eta mapatzeak helbide bera deskribatzen badute.
Hau helbide mapatzea da, ez portu mapatzea. Host bereko bi zerbitzu ezin dira honekin bereizi, eta IP helbideak bere karga erabilgarrian txertatzen dituen protokolo batek benetakoak ikusiko ditu oraindik.
Mapatzeak ez du itzulera-biderik sortzen
Itzulpena bezeroan gertatzen da, beraz zerbitzariak erantzunak tunelera bideratu behar ditu oraindik eta bere suebakiak oraindik baimendu behar ditu. Urruneko atebideak tunelaren subnetera nola iritsi ez badaki, eskaera iristen da eta erantzuna ate okerretik irteten da; mapatzeak hutsegitea bezeroaren arazo dirudiela egiten du soilik.
Zerbitzariaren aldeko arauek itzulpenaren ondoren zerbitzarian dauden helbideak deskribatu beharko lituzkete, ez bezeroak ikusten duen tartea. Aliasa baimen-arau batean kopiatzeak arratsalde bat galtzen du, alde horretako pakete batek ere ez baitu eramaten.
Aukeratu beste ezerkin talka egiten ez duen alias tarte bat, bezeroak bideratzen duen beste edozerrekin: beste VPN bat, edukiontzi-sare bat, bigarren bulego bat. Hemen talka egiteak jatorrizko anbiguotasuna zenbaki desberdin baten pean sartzen du eta zailagoa da ikusten, helbideak ezezagunak diruditelako.
Izenek eta karga erabilgarriek itzulpena gainditzen dute
Benetako 192.168.1.20-ra ebazten den host-izen batek arakatzailea gailu lokalera bidaltzen du urrunekora beharrean, bideratze-taulak esaten duena edozein dela ere. DNS pribatuaren erantzunak bezeroak ikusten duen tartea seinalatu behar du, TLS ziurtagiriak aplikazioak espero duen izena oraindik daraman bitartean. Probatu izenarekin, ez helbidearekin, helbideak funtziona dezakeelako izena isilka norabide okerrean ebazten den bitartean. Urruneko atebideak zona hori ere zerbitzatzen duenean, bere erregistroek ere bezeroak ikusten duen tartea behar dute.
Berbideratzeek, txertatutako URLek eta beren helbidea karga erabilgarrian ematen duten aplikazioek pakete-mapatze batek konpondu ezin dituen moduetan hauts daitezke. Hartu horiek aplikazio-arazo gisa eta neurtu ahalegina horren arabera, berrabidatzea beharrezkoa ez dela agindu aurretik.
Hiru egiaztapen konprometitu aurretik
Lehenik, berretsi bezeroaren implementazioa. Community OpenVPN-k aukera hau onartzen du; OpenVPN 3 kode-baseak onartu gabeko ezaugarrien artean zerrendatzen du, beraz Connect estiloko bezero bati bidalitako profil batek besterik gabe utz dezake. Onartu eta inoiz aplikatzen ez den direktiba batek errore batek baino okerragoa da, tunela osasuntsu dirudielako.
Bigarrenik, egiaztatu ibilbidea eta itzulpena bereizita diagnostiko-leiho labur batekin xehetasun handiz, eta gero probatu zerbitzu erreala ping bat beharrean. Hirugarrenik, berretsi router lokalak eta urruneko baliabideak bezerotik bereizgarri jarraitzen dutela, hori baitzen jatorrizko helburua.
Bezeroak itzulpena egin ezin badu, eskatu laguntza atebidearen aldetik edo onartu berrabidatze bat. Helbide bererako ibilbide gehiago gehitzea ez da diseinua.