LAN helbidea duen VPN bezeroa ez dago LANean

Bezeroa konektatu egiten da, 10.50.0.200 jasotzen du eta ezin du 10.50.0.20ko zerbitzaria lortu, bi zenbakiak /24 berean egon arren. Konfigurazio horren atzean dagoen ustea da LAN aurrizkitik datorren helbide batek bezeroa LANeko parte bihurtzen duela. Ez du egiten. Bezeroa puntutik punturako esteka batean dago, zerbitzariak helmuga lokaltzat hartzen du, eta falta den pieza inork bidaltzen ez duen bizilagun-erantzun bat da.

Mitoa: aurrizki bera segmentu bera da

Helbide-aurrizki batek ostalariari esaten dio zein helmuga lor ditzakeen zuzenean eta zeinek behar duten bideratzaile bat. Ez dio esaten helmuga nola dagoen fisikoki konektatuta, eta inola ere ez du bermatzen helmugak esteka-geruzako eskaera bati erantzun diezaiokeenik. Galdera desberdinak dira, ostalariko taula desberdinek erantzuten dietenak. Maskarak lehenari erantzuten dio eta bizilagunen taulak bigarrenari, eta lehenengoa soilik dago zure kontrolpean VPNaren aldetik.

Zerbitzariak 10.50.0.200ra bidaltzen duenean, helmuga bere maskararekin alderatzen du, helbidea on-link dela erabakitzen du, eta bertako segmentuari galdetzen dio zein den helbide horren jabe den hardware helbidea. Eskaera hori Ethernet interfazetik ateratzen da, eta VPN bezeroa ez dago han entzuteko.

Bezeroaren konfigurazioan ezerk ezin du hori bere aldetik konpondu. Erantzun-bidea LANean dagoen gailu batek bezeroaren izenean erantzutearen mende dago, edo bezeroak zerbitzariak lokal ez duen helbide bat izatearen mende.

Zer egiten duen tokiko ostalariak helbidearekin benetan

Jokabidea erraza da behatzeko eta merezi du ezer aldatu aurretik behatzea. Begiratu LAN ostalari baten bizilagunen taula bezeroa lortzen saiatu ondoren: osatugabea edo huts egindako sarrera da diagnosi osoa lerro bakarrean. Lerro horrek esaten dizu akatsa segmentuan bertan dagoela, ez tunelaren barruan nonbait.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

Bide-bilaketak helmuga on-link gisa emango du Ethernet interfazetik, eta horixe da arazoa. Bizilagun-sarrera osatugabea geratzen bada VPN saioa martxan dagoen bitartean, berretsi duzu falta den pieza esteka-geruzako ebazpena dela, ez bideratzea edo suebaki-politika.

Egin egiaztapen bera beste azpisare bateko ostalari batetik eta alderatu. Bideratzaile baten bidez bezeroa lortzen duen ostalariak ez du bizilagun-sarrerarik behar, eta desberdintasun hori diseinu-erabakia da miniaturaan.

Nola ematen duen proxy ARPk hurrengo jauzia

Proxy ARPk atebidea beste interfaz batetik lor dezakeen helmuga baten izenean esteka-geruzako eskaerari erantzutea lortzen du. LAN ostalariak hardware helbide bat jasotzen du, markoa atebidera bidaltzen du, eta atebideak paketea VPN saiora birbidaltzen du. Ostalariaren ikuspegitik bezeroa atebidearen atzean dagoela dirudi besterik gabe. Bezeroaren konfigurazioan ezer ez da aldatzen.

MikroTik-en RouterOS ARP dokumentazioak konektatutako LANaren helbide-espazioa maileguan hartzen duten dial-in bezeroentzat deskribatzen du erabilera hori. Mekanismoa bizilagun-ebazpenaren konponketa bat da, eta funtzionatzen du atebidea benetan bi bideetan dagoelako.

Hori ez da bezeroa LANera zubiratzea. Atebideak paketea zuzeneko saio aktibora birbidali behar du oraindik, eta bere bideratzeak eta suebaki-politikak zerbitzua onartu behar dute oraindik. Proxy ARPk aldatzen du nor den bizilagun-eskaerari erantzuten diona, ez nor den hitz egiteko baimena duena.

Irakurri arretaz plataformaren modu-izenak. RouterOSek proxy-arp eta local-proxy-arp bereizten ditu, eta bigarrenak interfaz beretik sartu eta irteten den trafikoa kudeatzen du. Ez dira trukagarriak diren idazkerak, eta biak bereizketarik gabe gaitzea ez da lasterbide bat.

Zer ez dizun ematen proxy ARPk

Ez du broadcast edo multicast bidezko aurkikuntzarik eskaintzen. Broadcast bidez zerbitzu bat aurkitu behar duen bezeroak huts egingo du oraindik, atebideak unicast saiora birbidaltzen duelako eta ez duelako bezeroa LANaren broadcast domeinuko kide bihurtzen. Broadcastaren mende dauden aurkikuntza-protokoloak ohiko iturri dira helbide mailegatuen diseinuetan gauza baterako funtzionatzen duela eta besterako ez dioen txostenen.

Ez du helbidea erreserbatzen. Mailegatutako zenbakia DHCP pool batean edo esleipen estatiko batean ere badagoenean, bi gailuk helbide bera izan dezakete eta ondoriozko jokabidea denboraren mende dago. Saio-hasiera arrakastatsua ez da erreserba bat.

Eta ez du LANaren jabearekin koordinatzeko beharra kentzen. Helbide-planaren jabea harritzen duen proxy ARP sarrera bat aste lasai baten zain dagoen euskarri-gorabehera bat da.

Konparazioa bereiz bideratutako pool batekin

Alternatiba VPN bezeroei beren aurrizkia ematea eta LAN ostalariei hara bideratzea uztea da. Orduan zerbitzariak off-link erantzunak bidaltzen dizkio bere atebideari, atebideak aurrizkia VPNaren muturrera bideratzen du, eta LAN segmentuan ez da bizilagun-ebazpenik behar. Hori pieza mugikor gutxiago da helbide mailegatu bat gehi proxy erantzun bat baino.

Diseinu hori errazagoa da pentsatzeko eta errazagoa auditatzeko, bezeroen tartea LANaren tarteetatik begi-bistan bereizita dagoelako. Bide bat, itzulera-bide bat eta sarbide-arau bat kostatzen ditu, proxy ARP diseinuak leku gutxiago nabari batean behar dituen gauza berberak.

Aukeratu ereduen artean nahita, ez ustekabean. Proxy ARPk harreman zehatz bat konpontzen du; bideratutako pool batek konponketa hori behar izatea saihesten du. Idatzi zein aukeratu duzun eta zergatik, eta hurrengo pertsonak ez du bizilagun-sarrera huts batetik berriro aurkitu beharko.