Gailu bakar batek bi norabideei egin diezaieke aurre aldi berean: ibiltzen diren erabiltzaileak barrurantz konektatzen dira, eta kaxa berak kanporantz konektatzen du irteerako hornitzaile batera, hautatutako trafikoa beste sare batetik atera dadin. Bi zerbitzuak gaitzeak minutu batzuk eskatzen ditu; elkarrekin bizitzeak diseinu bat eskatzen du, bigarren rolak lehenengoak men egiten dion bideratze-taularen berridazten duelako. Hiru baldintzek erabakitzen dute konponketak funtzionatzen duen: sarrerako zerbitzuak bere itzulera-bidea mantentzen duen, irteerako tunelak oraindik bere parekoa harrapatzen duen, eta aurrera bidali nahi zenuten trafikoa irteerarako hautatzen den. Bat gaizki eginez gero, bi tunel lortzen dituzu, biek konektatuta daudela jakinarazten dutenak, bien artean ezer erabilgarririk igarotzen ez den bitartean. Beheko egiaztapenek baldintza bakoitza finkatzen dute hutsegiteek normalean agertzen diren ordenan.

Izenda itzazu bi rolak edozein ezarpen ukitu aurretik

Idatz itzazu lau datu instantzia bakoitzeko: bere urruneko parekoa, autentifikazio-materiala, banatzen duen helbide-multzoa, eta haren atzeko sareak. Bi instantziak gailuan objektu bereiziak dira, eta zure oharretan ere bereizita egon beharko lukete. Geroago agertzen den sintoma nahasgarri ia guztia haien balioak nahastean sortzen da, eta ohar-multzo bat partekatzen duten bi instantzia dira multzo okerra eremu okerrean amaitzeko bidea.

Sarrerako zerbitzuak tunel-sare bat behar du, irteerako tunelaren helbideekin eta gailuak bideratzen duen edozein sare pribaturekin gainjartzen ez dena. Gainjartzea bi roletan aldi berean sintomak sortzen dituen akats bakarra da, eta askoz merkeagoa da paperean harrapatzea. Alderatu bi multzoak eta bideratutako sare pribatu bakoitza leku bakarrean, zerbitzuetako edozein konfiguratu aurretik.

Partekatutako hardwareak ez du kredentzial partekaturik esan nahi, eta urruneko sarbideko multzoko bezero-ziurtagiria ez litzateke irteerako hornitzailearen aurka erabilgarri izan behar. Material bereiziak errebokatzea erabaki lokal bihurtzen du, flota osoko gertaera izan beharrean.

Eduki itzazu zerbitzariaren erantzunak WAN bidean

Gailuak berak sortzen dituen erantzunak dira arduragabeko bideratze lehenetsi baten lehen biktima. Ibiltzen den erabiltzaile baten pakete kapsulatu bat iristen denean, erantzuna tokian sortutako trafikoa da, eta erabiltzaile hura iritsi zen interfazearen bidez atera behar du. Irteerako bezeroak hura harrapatzen duen bideratze lehenetsia instalatu badu, erantzuna tunel okerrean sartzen da eta saioa gelditzen da, zerbitzua oraindik osasuntsu dirudien bitartean.

Ez dago hau konpontzen duen kontrol-lauki bakarra, erabakia irteerako bezeroak zein trafiko harrapa dezakeenari buruzkoa delako. Edo ez tira ezazu ibilbiderik eta zuzendu hautatzen duzuna soilik, edo tira itzazu ibilbideak eta gehitu gailuaren beraren zerbitzuek funtzionatzen jarrai dezaten salbuespenak. Idatz ezazu aukera instantziaren ondoan, bestela hurrengo pertsonak bestea suposatuko du.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Irakur ezazu bideratze-taula bat-etortze luzeenaren arabera, ez ezer konfiguratu zenuen ordenaren arabera. Galdera da zein sarrerek irabazten duen irteerako parekoaren helbiderako eta zein sarrerek sarrerako zerbitzuaren erantzunerako, eta bi erantzun horiek desberdinak izan daitezke.

Ez utzi irteerako tunelari bere muturra jaten

Irteerako bezeroak bere parekoaren helbide publikoa harrapatu behar du tunela ezartzeko. Helbide hori bera tunelera bideratzen bada, bezeroak bere buztanari jarraitzen dio: garraioa ez da inoiz altxatzen, edo altxatu eta erortzen da ibilbidea instalatzen den unean. Erregistroa autentifikazio-denboraz gabeziaren itxura du, bideratze-hutsegitearena beharrean, eta horregatik ibilbideak merezi du lehen egiaztapena.

Egiaztatu ibilbidea kredentzialen aurretik eta berriro tunela altxatu ondoren, sarrera bat abioan zuzena eta minutu bat geroago okerra izan baitaiteke. Parekoaren helbideak WAN bide arruntera seinalatu behar du, inoiz ez tunel-gailura. Garraioa egonkortzen denean, galdera interesgarria aurrera bidalitako trafikora pasatzen da, hau da, hurrengo erabakia.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Aukera ezazu zein erabiltzailek lortzen duten irteera

Iturri-politika sarreran dagokio, trafikoa gailura sartzen den lekuan, beraz hautatu urruneko sarbideko multzoa edo haren barruko identitate estuagoak. Gorde itzazu inoiz irteerara bidali behar ez diren helburu pribatuak eta kudeaketa-salbuespenak, eta jar itzazu arau horiek zabalaren aurretik. Irteera-bideak bere itzulpen propioa edo bideratutako itzulera-antolamendua behar du orduan, eta horrek diseinu gehienetan irteerako interfazean multzoa estaltzen duen irteerako NAT esan nahi du. Itzulpenak ez du irteerarik aukeratzen; dagoeneko irten dena baino ez du berridazten, beraz NAT arau bat WAN arrotzean ez du ezer aldatzen hautaketan.

Egiaztatu urruneko muturrak diseinu honetatik aurrera bidalitako trafikoa onartzen duela, hornitzaile batzuek bai eta beste batzuek ez dutelako. Aldea konektatzen den eta ezer eramaten ez duen tunel gisa agertzen da, eta hori erraza da tokiko hutsegite gisa irakurtzeko. Probatu hiru fluxuak bereizita, independenteki huts egiten dutelako eta hirutik bi erdi egindako diseinua delako.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

Lehen komandoa ibiltzen den erabiltzailearen kanpoko konexioa da, eta funtzionatzen du bezeroak hasieratze-sekuentzia osatuta dagoela jakinarazten duenean. Bigarrenak, konektatutako ordenagailu hartatik exekutatuta, irteerako hornitzailearen helbidea jakinarazi beharko luke, zure WAN helbidea beharrean. Hirugarrena gailuan exekutatzen da multzoko helbide batera lotuta, eta aurrera bidalitako trafikoaren iturri-politika probatzen du, urruneko erabiltzailerik inola ere sartu gabe. Horren ordez WAN-etik erantzuten badu, politikak ez du bat egin, eta NAT editatzeak ez du hautapen-arazorik konpontzen.

Erabaki zer gertatzen den irteerak huts egiten duenean

Idatz ezazu hutsegite-jokabidea gertatu aurretik: irteerako tunela erortzen denean, erabiltzaileak WAN arruntera itzultzen dira edo blokeatuta geratzen dira irteera itzuli arte? Bi erantzunak defendagarriak dira, eta gailuak ez du zure ordez aukeratuko. Kentzen den ibilbide batek edo atezarri hil batera seinalatzen duen politikak ez du automatikoki blokeo osoaren emaitzarik sortzen. Blokeoa nahi baduzu, politikak berariaz esan behar du, eta irteera kenduta probatu behar da, hari buruz pentsatu beharrean. Atzerakada nahi baduzu, jakinarazi erabiltzaileei, isilpean bide arrunta hartzen duen trafikoa hain zuzen ere norbaitek estalita zegoela uste zuen trafikoa delako.

Desgaitu bezero-instantzia, begiratu konektatutako erabiltzaile batek oraindik zer harrapa dezakeen, eta abiarazi berriro. Denboraz gabetzen den eskaera eskatu zenuen blokeo osoaren emaitza da; WAN helbidearekin erantzuten duena dokumentatu ez zenuen atzerakada da. Errepikatu egiaztapena IPv6 eta DNS-rako, IPv4-rako idatzitako politikak ez baitu ezer esaten AAAA trafikoari buruz eta edozein tunelen bidez bultzatutako resolverrak galderak benetan irteten den lekutik erantzuten baitu.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Netgate-ren OpenVPN bideratuaren errezeta erakusten du nola egokitzen diren iturri-politika, interfaze-esleipena eta irteerako itzulpena, eta haren gune arteko irismena da osorik kopiatu behar ez den zatia. Esango ez dizuna hau da: goiko hiru baldintzetatik zein hautsi duen jada zure diseinuak.

Erlazionatutako artikuluak