L2TP helbide hori IPCP da, ez LANeko DHCP lizinga

Konexioa altxatzen da eta adaptadoreak bulegoko barrutiko helbide bat erakusten du, beraz ondorio naturala da VPNak LANeko helbide bat eman dizula eta, horrenbestez, LANean jarri zaituela. Horren bi erdietako bat ere ez da guztiz zuzena. L2TP PPP saio bat darama, eta PPPk IPCPrekin negoziatzen du barruko IPv4 helbidea. Helbide hori bi pareen artean adostutako saio-parametroa da, ez bulegoko DHCP zerbitzariak emandako lizinga, eta hura edukitzeak ez zaitu bulegoko kablean bizilagun bihurtzen.

Bi helbide konexio bakarrean

Bi negoziazio independente daude L2TP konexio batean. Kanpokoak bide babestua ezartzen du zure gailuaren eta VPNaren amaierako puntuaren artean, jada duzun sarearen gainean. Barrukoa PPP saioa da, eta han adosten dira zure saioaren helbidea eta beste muturrekoaren helbidea. Interneteko trafikoak erabat hirugarren helbide baten pean irten dezake, amaierako puntuaren helbide publikoaren pean, eta horregatik ez datoz bat VPN egiaztatzeko orria eta adaptadorearen helbidea.

Hiru rol horiek bereiz edukitzeak geruza honetara jendeak ekartzen dituen galdera gehienei erantzuten die. Zenbaki pribatu bat VPN interfazean normala eta espero daitekeena da. Ez du ezer esaten amaierako puntuak zure irteera publikoa aldatu duen ala ez, eta berez ez du erabakitzen zure trafikoak zein helmugara iristen den.

Zer egiten duen IPCPk zehazki

IPCP PPPrako IPv4 kontrol-protokoloa da. Alde bakoitzak nahi dituen aukerak deskribatzen dituzten Configure-Request mezuak bidaltzen ditu, eta helbide aukera horietako bat da. Helbiderik oraindik ez duen bezero batek normalean 0.0.0.0-rekin galdetzen du, eta zerbitzariak Configure-Nak-ekin erantzuten du, bezeroak erabil dezan nahi duen helbidea daramana. Gero bezeroak helbide hori eskatzen du, eta saioa helbide lokal eta urruneko batekin altxatzen da.

Truke hori PPP eta IPCP zehaztapenetan dokumentatuta dago, eta akats bat dirudien xehetasun bat azaltzen du: zerbitzariak bere politikaren arabera aukeratzen du helbidea, eta politika hori pool bat, erabiltzaile bakoitzeko ezarpen bat edo autentifikatutako identitateari lotutako helbide bat izan daiteke. Poolean helbiderik geratzen ez denean, edo politikak eskaerarekin talka egiten duenean, autentifikazioak arrakasta izan dezake helbidearen negoziazioak huts egiten duen bitartean, eta bezeroak inoiz egonkortzen ez den konexio baten berri ematen du.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

pppd erregistroko lerro batek helbide lokal bat eta urruneko bat aipatzen baditu, negoziazio horren amaiera arrakastatsua da. Haren ezean, autentifikazio arrakastatsuaren ondoan, helbidearen fasera seinalatzen du, ez kredentzialetara.

Zergatik ezin dizun LANak erantzun

Urruneko aldeko barrutiko helbide batek itxaropena sortzen du LAN horretako ostalariak zugana irits daitezkeela, eta gehienetan ezin dute, zerbitzariak zure saioaren helbidea tunelera itzultzen ez badu behintzat. Poolean egotea esleipenari buruzko adierazpena da, ez topologiari buruzkoa. Bulegoko fitxategi-zerbitzariak ez du zure saioaren helbiderako biderik VPN zerbitzariak birbidaltzen ez badu, eta agian ez dago baimenduta egiten badu ere.

Horregatik eragiten dute gainjarritako barrutiek itxurazko tamainarekin bat ez datozen arazoak. Pooleak bezeroak jada erabiltzen duen LAN batekin gainjartzen badu, bezeroaren bideratze-taulak bi erreklamazio ditu orain prefijo bererako, eta okerra izan ohi da nagusi tunelarekin zerikusirik ez duten arrazoiengatik.

Egiaztatu saioa, eta gero bidea

Egiaztatu lehenengo interfazea, gero bideak, gero garrantzitsua den helmuga bat. Urrats bakoitzak bere hutsegite-modua du, eta hirurak batera probatzeak geroago defendatu ezin duzun ondorio bat ematen du.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

Egiaztapen publikoak amaierako puntuaren helbidea erakusten badu eta helmuga pribatu bat denboraz kanpo geratzen bada, tunelek zure bide lehenetsia darama eta urruneko aldea ez da helmuga horretarako erantzuten ari. Helmuga pribatuak erantzuten badu baina egiaztapen publikoak ez badu aldatzen, profileko tunelak bananduta daude eta trafikoaren zati batek bakarrik erabiltzen du saioa.

Eduki hiru faseak bereizita

Autentifikazioa, helbideen negoziazioa eta birbidalketa modu ezberdinean huts egiten dute, eta bakoitzak jabe ezberdina du. Kredentzialak identitate-arazo bat dira, IPCP agortzea zerbitzariaren politikaren arazoa da, eta itzulera-bide bat falta izatea sare-diseinuaren arazoa da. Hirurak “VPNak matxura du” gisa jakinarazteak konponketa motela bermatzen du.

Idatzi esleitutako helbidea, zein pooletatik etorri zen eta LANak hura iritsi behar duen ala ez. Ohar bakar horrek hurrengo pertsonari eragozten dio DHCP lizing bat suposatzea eta inoiz parte hartu ez zuen barruti baten bila ibiltzea.