Zergatik OpenVPN bezeroaren blokeo-arau batek ez duen inoiz FORWARD lortzen

OpenVPN zerbitzari bereko bi bezerok elkarren berri izan dezakete haien pool-erako DROP arau bat gehitu arren. Araua FORWARD katean dago, trafikoa argi eta garbi dabil, eta arau horren kontagailuak zeroan jarraitzen du. Ondorio naturala suebakia hondatuta dagoela da. Gehienetan, ordea, paketeak ez du katea inoiz sartu.

Pare baten paketeak OpenVPN zerbitzari batetik jarrai ditzakeen bi bide daude, eta konfigurazioak erabakitzen ditu, ez suebakiak. Zein bide erabiltzen ari den jakiteak esaten dizu ostalariaren arau bat leku egokian ote dagoen.

Pare baten paketeak jarrai ditzakeen bi bideak

Barne birbidalketa aukera desgaituta dagoenean, A bezeroaren paketea tunel interfazera iristen da, B bezeroari esleitutako helbidearen barruan helburu bat duelarik. Zerbitzariaren bideratze-taulak tunel interfaze beretik itzultzen du, zerbitzariarenak baitira B-ren helbiderako bidea. Ostalariaren bidezko sarbide-irteera fluxua da, eta IPv4 birbidalketa bideak ebaluatzen du.

Barne birbidalketa aukera gaituta dagoenean, zerbitzari prozesuak paketea konektatutako bezero batekin parekatzen du eta bezero horri berari idazten dio. Paketea daemonaren barruan kudeatzen da eta ez da inoiz tunel gailuan berriro sartzen, beraz ostalariaren birbidalketa bidea erabat saihesten da. OpenVPN 2.6 eskuliburuak aukera hau bezero-arteko barne birbidalketa gisa deskribatzen du, eta horrexegatik ezin du ostalariaren suebaki-arau batek ikusi.

Hirugarren aldaera bat dago datu-kanala kernel modulu batera deskargatzen duten inplementazioetan. Birbidalketa erabakia eta zifratzea erabiltzaile-espaziotik ateratzen dira, eta netfilterrek fluxua ikusten duen ala ez deskarga-bidea nola eraikita dagoen araberakoa da. Ez ezazu inoiz pentsa arau-multzo zahar batek deskargatutako zerbitzari batean erabiltzaile-espazioko batean bezala jokatzen duenik. Berretsi modua martxan dagoen konfiguraziotik, ez paketearen bertsiotik.

Kontagailuak inoiz mugitzen ez denean

Zero kontagailuak esan nahi du paketeak ez ziola arau horri puntu hartan bat egin, eta hainbat arrazoi daude. Lehena goiko saihesbidea da: trafikoak ez zuen katea inoiz lortu. Bigarrena interfazean, noranzkoan, iturrian edo helburuan desadostasuna da, ohikoa pool-a birzenbatu zenean eta arauak oraindik aurrizki zaharra aipatzen duenean.

Hirugarrena posizioa da. Katean lehenagoko arau batek fluxua onar dezake zure DROP ebaluatu aurretik, eta geroagoko arau bat izan daiteke emaitza benetan erabakitzen duena. Irakurri katea ordenan kontagailuak ikusgai direla, eta gero egiaztatu zein arauren kontaketa handitzen den proba errepikatzean.

Egin truke kontrolatu bat bi bezeroren artean, haien benetako helbideak zerbitzariaren beraren egoeratik berretsi dituzunak, gogoratzen duzun maizter batetik ez. Dagokion kontagailua oraindik mugitzen ez bada, susmatu bidea parekatzea berridatzi aurretik. Mugitzen bada baina konexioak oraindik arrakasta badu, drop-a geroago gainidazten ari da eta ordena da arazoa. Erantzun horrek erabakitzen du konponketa arau-aldaketa edo topologia-aldaketa den, beraz lortu ezazu ezer editatu aurretik.

Iragazteko gai den muga bat aukeratzea

Politikak ostalariaren suebakian bizi behar badu, jarri trafikoa suebakiak ikus dezakeen tokian. Barne birbidalketa desgaitzea da pareen trafikoak tunel interfazea eta birbidalketa bidea zeharka ditzan lortzeko modu onartua, kostua pare pakete bakoitza ostalariaren pilatik pasatzea izanik.

Gero parekatu fluxua zehazki. Trafikoa tunel interfazera iristen da eta tunel interfazetik ateratzen da, bi noranzkoetan, beraz interfaze fisikoa soilik kontuan hartzen duten arauek ez dute bat egingo. Helbideetan oinarritutako arauek uneko pool-a behar dute, eta itzulera-noranzkoa zein aurrerakoa kontuan hartu behar dituzte.

Inplementazio askori hobeto zerbitzatzen die bezero edo talde mailan iragazteak, non identitatea ezaguna den eta politikak erabiltzailea jarraitzen duen, berrikonexioan aldatzen den helbide bat jarraitu beharrean. Hori ostalari-kate baten mekanismo ezberdina da, eta biak ez lirateke nahastu behar arrazoi argirik gabe.

Ez eraman topologia zahar baten arau-multzoa migrazio batetik aldaketarik gabe. Helbide-pool-ek, interfaze-izenek eta birbidalketa-moduek guztiek eragiten dute arau bat bat datorren ala ez, eta lehen funtzionatzen zuen arau kopiatu bat da froga motarik engainagarriena. Hasi baimendu nahi duzun fluxutik eta idatzi harekin bat egiten duen araua.

Isolamendua probatzea arau batean fidatu beharrean

Proba ezazu debekatutako kasua eta baimendutako kasua exekuzio berean. Hasi konexio berri bat bezero batetik bestera eta berretsi huts egiten duela, gero berretsi baimenduta egon beharko lukeen konexio batek oraindik funtzionatzen duela. Lehena soilik probatzen bada, dena blokeatzen duen suebaki bat arrakasta dirudi.

Errepikatu zerbitzariaren konfigurazioa berriz kargatu ondoren eta bezero bat berriz konektatu ondoren, barne birbidalketa eta pool-esleipenak exekuzio-denborako egoera baitira. Egiaztatu kontagailuak bi noranzkoetan, noranzko batekin bat egiten duen eta erantzunarekin bat egiten ez duen arau batek isolamendu partziala sortzen baitu, proba azkar batean nabaritzeko zaila dena.

Isolamendua fluxua benetan daraman mugan behatutako emaitza da. DROP arau bat ostalariaren nonbait ez da froga; huts egindako konexio bat eta hura eragin zuen arauaren kontagailu mugitua dira froga.