LAN bideratzailea eta VPN bezeroa: bi gailu, bi bideratze-taula
Bideratzailearen hurrengo jauziak bezeroari bakarrik ematen dizkio paketeak. Gehitu bezeroaren tunel-bidea, birbidalketa eta itzulera-bide bat, eta gero probatu LANeko ostalari batetik.
Bi gailuk paketea birbidaltzen dute eta bakoitzak bere taula mantentzen du. LAN bideratzaileak badaki urruneko aurrizkia VPN bezeroarena dela, eta VPN bezeroak badaki nola iritsi aurrizki horretara bere tunelaren bitartez. Konfigura ezazu lehen taula soilik eta paketea bat datorren biderik ez duen makina batera iristen da, beraz lehenetsitik ateratzen da berriro. Hori da hutsegite osoa, eta LANetik begiratuta bideratze-begizta bat dirudi, ia-ia hala delako.
Marraztu bi jauziak bider bat ukitu aurretik
Hartu diseinu adierazgarri bat: LANeko ostalariak 192.168.50.0/24 helbidean, bideratzaile arrunta 192.168.50.1 helbidean, bezero dedikatu bat 192.168.50.15 helbidean eta urruneko LAN bat 10.60.0.0/24 helbidean, bezero horrek duen tunelaren bitartez soilik iristeko modukoa. Bi barruti pribatuetako batek ez du bestea gainjartzen, eta tunelak bere helbide-plana du.
Bi barruti pribatuek garrantzia dute, zein gailuk erantzun dezakeen erabakitzen dutelako. Urruneko aldeak paketea bezeroaren tunel-helbidetik iristen ikusiko du, eta haren erantzunak 192.168.50.0/24 helbidera itzultzeko bidea aurkitu behar du. Irteerako noranzkoa soilik konfiguratuta badago, eskaerak funtziona dezake erantzuna desagertzen den bitartean.
1. urratsa: zuzendu bideratzailea bezeroari, ez tunelari
LAN bideratzailean, gehitu helmuga-bide bat hurrengo jauzia bezeroaren LAN helbidea duena:
ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55
Erregistro horrek «eman tunela egin dezakeen makinari» dio. Ez du ezer esaten tunela nola eraikitzen den, eta ez du bezeroaren berezko bidea ordezkatzen. Bideratzaile kudeatu batean baliokidea gailuaren bide estatikoen orrialdean bizi da; Linux bideratzaile batean LANaren jabe den interfazearen konfigurazioan dagokio, ez duzun shell batean.
Egiaztatu bigarren komandoaren erantzuna. Bezeroa gateway gisa eta LAN interfazea device gisa ematen baditu, lehen jauzia zuzena da eta gainerako lana beste makina batean dago.
2. urratsa: eman bezeroari bere bide propio bat tunelaren aldean
Bezeroak orain 10.60.0.0/24 helbiderako pakete bat jasotzen du eta bere taula kontsultatzen du. Bere tunel-konfigurazioak aurrizki horretarako bide bat instalatu badu, paketea zifratuta jarraitzen du. Ez badu egin, paketea lehenetsi arruntarekin bat dator eta 192.168.50.1 helbidera itzultzen da, eta horrek bezeroari berriro bidaltzen dio.
Begiratu zerbait gehitu aurretik:
ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward
Taula guztietan aurrizki-biderik eza da bilatzen ari zaren aurkikuntza. Gehitu tunelaren beraren konfigurazioaren bidez, hurrengo berriz konektatzean berriro instalatu dezan; eskuzko ip route add saioarekin desagertzen da eta hutsegitea une desegokienean itzularazten du. Hurrengo jauzia tunelaren interfazea edo VPNak pare gisa esleitzen duen helbidea da, bezeroaren arabera, eta parearen helbidea uneko profilatik etorri behar da, ohar zahar batetik beharrean.
Begizta, gertatzen denean, ez da praktikan infinitua: TTL jaisten da urrats bakoitzean eta paketea denbora gaindituari buruzko mezu batekin hiltzen da. Horregatik traceroute errepikatuak ziklo bat iradoki dezakeen bitartean, birbidaltzen ez duen bezero batek pakete bera isilka baztertzen du.
3. urratsa: baimendu birbidalketa eta aukeratu itzulera-bidea
Jasotzea eta birbidaltzea baimen desberdinak dira. Bezeroan net.ipv4.ip_forward=1 kernel mailan trantsizioa ahalbidetzen du, eta suebaki-arau batek oraindik baimendu behar du LAN interfazearen eta tunelaren artean. Bezeroaren beraren kudeaketa-orrialdera sarbidea ematen duen arauak ez du urruneko LANera trantsiturik baimenduko, eta bereizketa erraza da oharkabean pasatzen ostalari berak ping-ak lokaletik erantzuten dituenean.
Urruneko aldeak ispilu-arazoa du. Jakin behar du 192.168.50.0/24 konektatutako bezero honen bidez irisgarria dela. OpenVPN erabiliz, horrek normalean esan nahi du zerbitzariaren konfigurazioak bultzatutako bezero bakoitzeko bide bat, edo zerbitzarian bezeroaren atzeko LANa deklaratzen duen bezeroarentzako fitxategi bat. Hori gabe, urruneko LANak erantzuna baztertzen du edo bere lehenetsitako atebidera bidaltzen du, hau da, internet-era.
Iturriaren itzulpena da alternatiba LANaren aurrizkia iragarri ezin denean. Bezeroan masquerade arau mugatuak iturria tunel-helbidera berridazten du, eta erantzunak naturalki itzultzen dira orduan. Eskaria egin zuen LANeko ostalaria nor zen ere ezkutatzen du, eta berez ez dio urruneko aldeari barrurako konexioak hasteko baimenik ematen. Aukeratu truke hori nahita, masquerade orokorra gehitu eta albo-ondorioa geroago aurkitu beharrean.
4. urratsa: egin bi erabakiak iraunkor, eta gero probatu benetako bidea
Bide bakoitzak jabe bat du, eta jabea abioan edo berriz konektatzean birsortzen den konfigurazioa da. Bideratzailean bide estatikoaren sarrera bat izan daiteke; bezeroan VPN profila, NetworkManager edo systemd-networkd izan daiteke. Egiaztatu tunela berriz konektatuz eta bezeroa berrabiaraziz, eta gero irakurri taula berriro, aldaketari fidatu beharrean.
Mantendu ukitu gabe tunelaren kanpoko konexioa daraman lehenetsitako bidea. Konfigurazioa «errazteko» ordezkatzeak bide zifratua hausten du barneko trafikoek erabili aurretik, eta sintoma aldaketaren ondoren inoiz berrezartzen ez den tunel bat da.
Probatu LANeko ostalari arrunt batetik, ez bezerotik, bezeroan sortutako eskaerak ez baitu inoiz bideratzailearen lehen jauzia erabiltzen. Ekarri urruneko LANean soilik dagoen zerbitzu bat eta egiaztatu erantzunaren gorputza, eta gero begiratu bezeroaren kontagailuak edo erregistroak trantsizioa gertatzen dela ikusteko. Barneko traceroute batek jauzi pribatuak erakusten baditu, birbidalketa frogatzen du, ez zifratzea: kanpoko bidea behaketa bereizia da, eta tunelaren interfazearen kontagailuek soilik erakusten dute haren bidez zer atera zen.