VPN bezeroek zerbitzarira iristen dira, baina ez LANera: zein konponbide?
Tunela altxatuta dago eta ateak erantzuten du, baina atzean dauden ostalariek isilik jarraitzen dute. Aukeratu ibilbide estatikoa urruneko LANean, NAT zerbitzarian edo bigarren tunel bat.
Bezeroak OpenVPN zerbitzariaren tunel helbidera ping egiten du eta erantzuna jasotzen du, gero zerbitzariaren LANeko ostalari bat probatzen du eta ezer ez du jasotzen. Bereizketa horrek hutsa asko murrizten du: tunela altxatuta dago, aurreratzeak ziurrenik funtzionatzen du, eta erantzuna itzultzen ez den ate batetik irteten da. Hiru konponbide daude, eta egokia zeri eusten diozun eta zer uzteko prest zauden araberakoa da. Erantzun beheko hiru galderei hurrenez hurren eta hautua ez da gustu kontua izango.
Lehenik, zein norabide dagoen hautsita egiaztatu
Eskaera tunel interfazera iristen da VPN igerilekuko iturburu helbide batekin. Zerbitzariak LANeko ostalarira bidaltzen du, eta ostalari horrek bere taulak izendatzen duen ateari erantzuten dio, normalean LANeko bideratzaileari. Bideratzaileak igerilekurako ibilbiderik ez badu, erantzuna han hiltzen da edo internet aldera noraezean ibiltzen da.
Bi makinak probatu bat ere aldatu aurretik. Galdetu zerbitzarian bideratze taulari nola iritsiko litzatekeen bezero batera; galdetu LANeko ostalariari nola iritsiko litzatekeen helbide berera. Lehen bilaketak tunela seinalatzen du normalean eta bigarrenak LANeko bideratzailea, eta alde hori da hutsa lerro bakarrean. Bi bilaketak suebakiaren auditoria bat baino merkeagoak dira eta arazoaren norabidea finkatzen dute.
ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forwardLANeko ostalariak jada VPN zerbitzaria seinalatzen badu, zure arazoa suebaki arau bat edo MTU muga bat da, ez falta den itzulera bide bat. Ez gehitu ibilbiderik iragazki bat konpontzeko.
Lehen galdera: urruneko LANeko bideratzailea editatu dezakezu?
LANeko bideratzailea zurea denean, erantzun garbia VPN igerilekuranzko ibilbide estatikoa da, VPN zerbitzariaren LAN helbidea hurrengo jauzi gisa duela. Bezeroen iturburu helbideak osorik mantentzen ditu, eta hori garrantzitsua da LANeko ostalariek helbidearen arabera erregistratu, iragazi edo abiadura mugatzen dutenean. Zerbitzarian itzulpenik ere ez du behar, beraz tunela bideratze bide hutsa izaten jarraitzen du. Sortzen duen betebeharra dokumentazioa da, igerilekuak, ibilbideak eta zerbitzariaren konfigurazioak bat etorri behar dutelako.
Isilpean huts egiten du norbaitek igerilekua aldatzen duen egunean. Idatzi balioa behin eta hartu hiru lekuren edozeinetan egindako aldaketa hiruretan egindako aldaketatzat.
Zerbitzua ostatatzen duen NAS edo layer 3 kommutadoreak ibilbide bera behar du, dena ibilbide hori duen bideratzaile batetik bidaltzen ez badu. Egiaztatu azpisarea amaitzen duen gailua, internet aldera begiratzen duena soilik ez. Sare txikiek sarritan hiru gailu izaten dituzte bideratzeaz iritzia dutenak.
Bigarren galdera: LANak bezeroen helbideak ikusteari utz diezaioke?
Bideratzailea beste norbaitena denean, VPN zerbitzarian itzultzeak ez du lankidetzarik behar. LANeko ostalariak zerbitzariaren LAN helbidea ikusten du, hari erantzuten dio, eta zerbitzariak atzera itzultzen du. Horregatik jokatzen dute horrela gailuek eta NATen oinarritutako urruneko sarbide rolak.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADEPrezioa egiaztapena da: bezero bakoitzeko helbideak LANeko erregistroetatik desagertzen dira. Orduan LANeko ostalarian dagoen edozein baimen zerrendak zerbitzaria izendatu behar du, igerilekua beharrean.
Hautatu itzultzea lankidetza eskuragarri ez dagoenean, ez deserosoa soilik denean. Bezeroa etorkizuneko ikerketa orotatik ezkutatzen du, zein eramangarrik konexioa ireki zuen jakin behar duzunetatik ere. Helbideak kargean txertatzen dituzten protokoloak ere hauts ditzake, itzultzea goiburuan bizi delako. Inongo aukerak ez du aurreragokoagorik; jabetzari buruzko galdera desberdinei erantzuten diete.
Hirugarren galdera: zerbitzaria bera beste tunel baten bezeroa al da?
Imajinatu beste topologia: VPN zerbitzariak hornitzaile komertzial bat ere deitzen du, beraz bi tunel eta bi helbide multzo ditu. Bere bezeroentzat aurreratzen duen trafikoa hornitzailerik ateratzen da, eta hark ez ditu erantzunak igerilekuko helbideetara bideratuko. Horregatik desagertzen dira erantzunak bi tunelak osasuntsu egon arren.
Konponbidea irteerako tunela ere maskaratzea da, hornitzaileak zerbitzariaren tunel helbidea soilik ikus dezan. Aurkako norabideak bere araua behar du, zerbitzaria bere bezero bati konexioa hastea beste fluxu bat delako. Arau hori gabe bezeroak bideratu ezin duen helbide bati erantzuten dio. Jarri arau estua maskaratze zabal ororen aurretik, itzulpen zehatzak irabaz dezan.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1Interfaz anitzeko ostalariek antzeko huts bat gehitzen dute, bezeroaren aldetik berdin ikusten dena. Erantzuna metrika txikiagoko interfazetik ateratzen da, iturburu helbidea beste taula batetik aukeratu delako. Egiaztatu itzulera bidea bilaketa batekin, joateko bideak hura inplikatzen duela suposatu beharrean.
Gero egiaztatu bi norabideak eta bi tamainak
Aldaketaren ondoren, egin ping bezerotik LANeko ostalari batera eta gero LANeko ostalaritik bezerora. Bigarren norabidea da jendeak saltatzen duena, eta hura da itzulpen arau osatugabea agerian uzten duena. Erregistratu bi emaitzak denbora marka batekin, geroagoko erregresio bat alderagarria izan dadin.
Gero mugitu benetako datuak, ping txiki bat lortzen denean transferentzia handi bat trabatzea MTUren sintoma delako. Huts hori ibilbidea konpondu duzulako zoriondu eta berehala agertzen da.
Azkenean, probatu berriro berrabiaraztearen ondoren. Exekuzio denborako ibilbide eta suebaki aginduak ez dira hortik bizirik ateratzen, eta hurrengo abioan desagertzen den konponketa testuinguru gutxiago duen norbaitek diagnostikatuko du berriro. Egin aldaketa iraunkorra zure sistemak jada egiten duen moduan, eta gero berrabiarazi behin nahita.