Access Server-eko gateway erabiltzailea: bezero baten adarraren LANa bideratzea

OpenVPN bezero baten tunel helbideari ping egin diezaiokezu eta, hala ere, atzean dagoen LANeko inolako ostalaririk ez iritsi. Access Serverrek VPN pool-etik helbide bat ematen dio bezeroari, eta pool helbidea da zerbitzariak berea dela dakiokeen gauza bakarra. Adarraren prefixua bereiz deklaratu behar den egitatea da, eta hori egin ondoren ere adarrak birbidaltzaile bat behar du eta egoitzak itzulera-bide bat. Leku okerrean idatzitako bideak konponbidea dirudi eta ez du ezer aldatzen.

Bi helbide, bi jabetza-erreklamazio desberdin

Bezeroa konektatzen denean, Access Serverrek konfiguratutako VPN pool-etik helbide bat esleitzen dio, adibidez 10.90.0.0/24. Esleipen hori ostalari bakarrerako maiztertza bat da. Konexioak ez du esaten bezero bera 10.60.0.0/24-ren aurrean ere badagoenik, eta zerbitzariak ez du asmatuko: LAN prefixua bezero zehatz baten bidez iristeko modukoa da administratzaile batek deklaratzen badu soilik.

Horregatik ez du balio beste makina batean bide estatiko bat jartzeak. Bideak dio bidali 10.60.0.0/24 helbide honetara, baina helbidea gateway gisa markatu ez zen bezero batena bada, zerbitzariak ez du arrazoirik pakete horiek hara eramateko, eta bezeroaren pilak baztertu ditzake. Deklarazioa eta bidea mekanismo beraren bi erdiak dira.

Zer instalatzen du gateway ezarpenak benetan

Admin Web UI-n deklarazioa erabiltzaile-propietatea da: gaitu Configure VPN gateway konektore erabiltzailean eta sartu adarraren benetako prefixua Network on the VPN client side eremuan. Erabiltzaile hori beste edozein bezala autentifikatzen da, beraz, gainbegiratu gabeko gailu baterako egokia den kredentzial-politika behar du, eta hasierako saio automatikoaren profila sekretua da, ez erosotasun-fitxategia.

Laukitxo horren atzean zerbitzariak prefixua bezero horren pool helbidearen bidez iristeko modukoa dela tratatzen du, eta Access Controls-en bideratze-konfigurazioak erabakitzen du beste bezeroei zer esaten zaien: ohiko bezeroei bidaltzen zaizkien bideak eta egoitzako sareetatik bezeroen helbide eta azpisareetara trafikoa uzten duten sarbide-arauak. Gaitu bideratzea adarrera iritsi behar duten sareetarako, eta mantendu baimendutako zerrenda labur.

Sortutako fitxategi batean itsatsitako Community estiloko direktiba bat ez da eredu honetan parte hartzen. Produktua da bidaltzen duen bideratze-taularen jabea; eskuz editatutako lerroa hurrengo sorkuntzan gainidazten da edo ezikusi egiten zaio.

Osatu bi sareen itzulera-bideak

Plan zehatza: egoitza 10.40.0.0/24, adarra 10.60.0.0/24, VPN pool 10.90.0.0/24, eta Access Server egoitzaren aldeko helbide pribatu batean eskuragarri. Egoitzako bideratzaileak adarraren prefixurako eta poolerako bideak behar ditu, biak Access Serverrerantz. Hauek gabe tuneletik eskaera doa eta erantzuna gateway lehenetsitik irteten da, ohiko konexio erdiirekia sortuz.

Adarrean konektoreak bere burura zuzenduta ez dauden paketeak birbidali behar ditu: IP birbidalketa bere sistema eragilean eta tuneleko eta LANeko interfazeetara mugatutako birbidalketa-baimena; Linuxen net.ipv4.ip_forward=1 da forward katearen arauekin, Windowsen routing and remote access. Gero adarreko ostalariek itzulera-bide bat behar dute: edo konektorea da haien gateway lehenetsia, edo lehendik dagoen gatewayak egoitzaren eta poolaren prefixuetarako bide zehatzak daramatza.

Konektorearen bideratze-taulak ez ditu adarreko LANeko ostalari guztiak berriz konfiguratzen. Ostalariek beste bideratzaile bat erakusten badute, itzulera-bideak han dagoz, eta hark onartu behar du ikusten duen iturburu-helbidea ez dela tokiko azpisareko bizilaguna.

Irakurri hutsa bide gisa, ez baimen gisa

Egiaztatu orden finkoan. Lehenik Access Servertik adarreko ostalarira baimendutako zerbitzu bat, gero zerbitzu bera egoitzako ostalari arrunt batetik, gero kontrako noranzkoa politikak uzten badu. Lehenak pasatzen badu eta bigarrenak huts egiten badu, bidalitako bideak edo sarbide-arauak dira arazoa. Biek pasatzen badute baina erantzunik iristen ez bada, aztertu adarreko birbidalketa eta egoitzako itzulera-bidea.

Ostalariaren suebakia da hurrengo susmagarria, bideratutako sarbidearekin helmugak egoitzako edo pool helbide bat ikusten baitu iturburu gisa. Tokiko azpisarerako idatzitako arau bat ez dator bat, eta paketea baztertu egiten da bideratzea primeran ibili ondoren.

Bi diseinuk hau baino gehiago behar dute. Lekuen arteko prefixu gainjarriek helmuga anbiguoa egiten dute eta berrenumerazioa edo itzulpena behar dute, eta Access Server klusterratuak nodo bakoitzak adarreko konektorerako bide funtzionala izatea behar du, ez nodo bakar bat bidea eutsiz. Aplikatu aldaketak gordetzeko eta eguneratzeko bide arruntetik, konektorea berriro konektatu eta egiaztatu bi muturretatik; makina guztien berrabiarazte osoa ez da prozeduraren parte.

Access Serverren site-to-site tutorialak ezarpen berak zerrendatzen ditu produktuaren ordenan; merezi du behin jarraitzea diseinua zeure prefixuetara egokitu aurretik.