Zergatik ez dituzten OpenVPN bezeroek gatewayaren IPsec hautatzaileak harrapatzen

Egin ping gatewaytik urruneko IPsec tunelaren atzean dagoen ostalari batera eta garbi erantzuten du, beraz tunela osasuntsu dirudi eta txartela aurrera doa. Gero konektatutako bezero batek ostalari bera probatzen du eta ez du ezer jasotzen. Ping hura ez zen inoiz bezeroaren fluxuaren froga, gatewayaren beraren iturburu-helbidearekin irten zelako eta beste IPsec hautatzaile batekin bat egin zuelako. Bi kasuak zergatik aldentzen diren ulertzea da konponbidearen zatirik handiena.

Gatewayaren pingak zure bezeroak inoiz erabiltzen ez duen fluxu bat probatzen du

Iturburu-helbideak erabakitzen du zein politika aplikatzen den. Gatewayn sortutako pakete bat bere LAN lokaleko edo tunelaren muturreko helbide batekin ateratzen da, eta harekin bat egiten duen politika kasu horretarako bertarako idatzi zen. Bezero baten paketea OpenVPN interfazean iristen da bezero-poolaren helbide batekin, guztiz beste hautatzaile bat dena.

Horregatik hutsak bideratze-arazo bat dirudi, benetan politikaren irismenaren arazoa den arren. Gatewaytikako irisgarritasunak parekidea bizirik dagoela eta proposamenak negoziatu zirela frogatzen du, eta ez du ezer frogatzen poola babestuta dagoen ala ez.

Bultzatu aplikazioak benetan behar duen urruneko aurrizkia

Hartu 10.8.0.0/24 bikote ilustratiboa konektatutako bezeroentzat eta 172.30.239.0/25 urruneko sare babestuarentzat. Bezero batek bigarren aurrizki horretarako bidea behar du, ez gatewayaren LANera eta ez beste tunel-helbide batera. Poolera bultzatutako bide bat da bezeroak trafiko hori gatewayri ematea eragiten duena. Hura gabe, paketea ez da inoiz iristen ari zaren arazketa-politikaren erabakira.

Bultzatutako bideak onartzen dituen Community zerbitzari batean, direktibak benetako maskara hartzen du: push "route 172.30.239.0 255.255.255.128". Access Serverrek helmuga bera konfiguratzen du instalatutako bertsioaren sare pribatu edo sarbide-arau ezarpenen bidez, bideratutako edo itzulitako modua nahita aukeratuta. Sortutako suebaki-kateak jabeen konfigurazioaren ordez editatzea da funtzionatzen duen instalazio bat erreproduzitzeko ezinezko bihurtzen duena.

Konektatu ondoren, irakurri bezeroaren bideratze-taula, ez zerbitzariaren asmoa. Poola soilik estaltzen duen bide batek bultzada ez zela iritsi esan nahi du, eta tunelaren bidezko bide lehenetsia eskakizun hau baino zabalagoa da eta geroago harrituko zaitu. Egiaztatu maskara zein aurrizkia, /25 gisa /24 gisa bultzatzeak ondoko helbideen trafikoa eraman ezin duen bide batera bidaltzen baitu. Gero berretsi bezeroak helmuga horretarako tunel-interfazea aukeratu zuela.

Egin hautatzaileek bezero-poola barne har dezaten

Bezeroen helbideak mantentzen dituen sarbide bideratuarentzat, IPsec politikak poolaren eta urruneko aurrizkiaren arteko trafikoa babestu behar du. Gatewayaren LANerako idatzitako hautatzaileek pinga onartzen dute eta bezeroaren eskaera baztertzen dute, eta horixe da ikerketa hau hasi zuen asimetria.

Aztertu negoziatutako politika eta konfiguratutako proposamenak ere, adibidez ipsec statusall erabiliz strongSwanen edo zure inplementaziorako baliokidea den egoera-komandoarekin. Politikan oinarritutako IPsec-arekin, bide arruntak interfaze fisiko batera seina dezake trafiko bateragarria oraindik zifratuta dagoen bitartean, beraz falta den tunel-gailuak ez du ezer frogatzen. Konparatu hautatzaile-bikoteak idatzi dituzun pool eta aurrizkiarekin.

Gatewayko iturburu-NAT orokorrak bat-etortzea hautsi dezake ere. Masquerade arau batek bezeroaren iturburua politikaren egiaztapenaren aurretik berridazten badu, paketea ez da jada idatzi duzun hautatzailea bezalakoa. Hori da masquerade arau zabal bat bigarren VPN baterako konponbide txarra izateko arrazoi bat: zein politika aplikatzen den eta urruneko aldeak zein helbide erregistratzen duen aldatzen du. Salbuetsi bideratu nahi duzun trafikoa, edo itzuli nahita eta eguneratu hautatzaileak.

Aukeratu bideratzea edo itzulpena nahita

Bideratzeak bezeroaren helbidea urruneko aldearentzat ikusgai mantentzen du, beraz urruneko erregistroek eta iturburu bakoitzeko arauek zentzua izaten jarraitzen dute, eta urruneko gatewayak poolera itzultzeko bidea ezagutzea eskatzen du. Itzulpenak poola helbide bakar baten atzean ezkutatzen du, eta horrek itzulera-bidearen arazoa kentzen du eta bezero bakoitzaren identitatea suntsitzen du.

Aukeratu diseinu bat eta idatzi, biak hautatzaile desberdinak eta suebaki-ordena desberdina behar dituztelako. Erdi aplikatutako masquerade bat bien artean geratzen da eta ez du bat ere asetzen. Idatzitako hautua da hurrengo ingeniariari akats bat eta erabaki nahita bat bereizteko aukera ematen diona.

Itxi begizta aurreratzean eta erantzunean

Gatewayak zuk nahi duzun protokoloa eta helmuga aurreratu behar ditu, hau da, IP aurreratzea gaituta eta bikotea onartzen duen aurreratze-katea. Gero urruneko aldeak erantzunak IPsec bidetik itzuli behar ditu, eta hori haien gatewayko bideratze-erabakia da, ez zurea. Bi erdiak konfigurazio arrunta dira, eta biak erraz geratzen dira erdi eginda. Probatu bereizita, falta den aurreratze-arau bat hondatutako tunel batekin nahas ez dadin.

Egiaztatu bezero batetik aplikazio baterako eskaera erreal batekin, OpenVPN interfazea, IPsec erabakia eta urruneko ostalaria zeharkatzen ikusiz. Aztertu erantzuna behaketa bereizi gisa, iristen den eskaera batek eta inoiz itzultzen ez den erantzun batek berdin itxura baitute bezeroaren lekutik. Jarraitutako eskaera batek edozein gateway-ping baino gehiago balio du.

Mantendu helmugaren baimena estu probatzen ari zaren bitartean, eta berretsi araua ez duen bezero batek ezin duela zerbitzura iritsi. Instalatutako bide bat eta ezarritako asoziazio bat ez dira emandako sarbide bera.