OpenVPN zerbitzaria eta bezeroa host berean: zergatik erortzen dira bezeroak
OpenVPN zerbitzatzen eta era berean erabiltzen duen host batek tunela altxatuta eduki dezake tokiko bezeroek erantzunak galtzen dituzten bitartean. Bi gauzek azaltzen dute: partekatutako igerileku batek eta bide lehenetsi berri batek.
Gehitu bezero-profil bat VPN zerbitzari bat jada exekutatzen duen makinari, eta jatorrizko zerbitzua izango da lehen biktima. Tunel berria agian ez da inoiz ezarriko, edo altxatu egingo da zerbitzariaren lehendik dauden bezeroek isilean erantzunak jasotzeari uzten dioten bitartean. Bi talkak sortzen dute bi emaitza: jada erabiltzen ari den tunel-igerileku bat, eta bezeroaren erdi berriak instalatutako bide lehenetsi bat, taula osoa estaltzen duena. Inork ez du OpenVPN errore-mezurik sortzen, eta horregatik hutsegitea zerbitzariaren arazo gisa irakurtzen da.
Makina bat, bi rol, eta erantzunak norantz joan behar dutenari buruzko bi erantzun bateraezin.
Igerileku bera, bi zerbitzari: nork irabazten du
Zerbitzari-instantzia bakoitzak bere tunel azpisarea behar du. server 10.8.0.0 255.255.255.0 bezalako lerro bat bigarren konfiguraziora kopiatzeak bi instantziei aurrizki bera ematen die, eta emaitza abiarazteari uko egitea edo isilpeko lehia bat izaten da, non zerbitzari baten bezeroek besteak ere bereizat jotzen dituen helbideak jasotzen dituzten. UDP portu desberdinek eta gailu-izen desberdinek ez dute laguntzen, ez batek ez besteak ez baitu helbide-espazioa ukitzen. Aldatu bigarren igerilekua, eta aldatu bideek aipatzen duten leku guztietan.
Zer dagoen bizirik zerrendatu editatu aurretik: ip -4 addr show-ek tunel gailuak zerrendatzen ditu, ss -lunp-ek entzuleak, eta systemctl list-units-ek unitateak izendatzen ditu. Tunel helbideei begirada bat nahikoa da igerilekuak talka egiten duten erabakitzeko.
Zer gehitzen dion bezero-profilak taulari
Bezeroaren erdiak bideak idazten ditu konektatu bezain laster. redirect-gateway def1-ek bide lehenetsia 0.0.0.0/1 gehi 128.0.0.0/1 banatzen du, biak gailu berritik bideratuta, urruneko zerbitzarirako host-bide batekin batera, fisikoki interfaze fisikora nahita lotuta dagoena. Lotura hori tunelak bere garraiorako bidea gordetzeko dago. Gainerako guztiak, zerbitzari lokalak bere bezeroei zor dizkien erantzunak barne, bide lehenetsi berriari jarraitzen dio orain eta urruneko estekatik irteten da.
Beraz, bigarren talka ez da tunel hautsia. Taulako leku okerrean dagoen tunel funtzionala da.
Rolak bereizita edukitzeko hiru modu
Inbasio gutxieneko konponbideak bide lehenetsia bezero-profilatik kanpo mantentzen du: route-nopull gehi route lerro esplizituak urruneko aurrizkientzat, tokiko taula eskatu duzun lekuan soilik alda dadin. Hurrengo urratsa tokiko tunel azpisarea salbuesten duen politika-araua da, bezero lokalei erantzunak iritsi ziren interfazetik irten daitezen, bide lehenetsia badago ere. Sakonena bezeroaren rolerako sare-namespace bereizia da, partekatutako taula guztiz kentzen duena eta mantentzeko bigarren bideratze-testuinguru bat eskatzen duena.
Edozein bide hartuta ere, salbuespenak tokiko tunel azpisarea izendatu behar du, ez LAN-a. Zerbitzari lokalak bidaltzen duen erantzunak tunel helbide bat du helmuga, beraz LAN formako salbuespenak ez du inoiz bat egiten.
Bi instantzietatik zein da erruduna
Geldiarazi bezero-instantzia eta probatu berriro jatorrizko bezeroak. Berehalako berreskurapenak bideratzea esan nahi du, ez zerbitzaria. Ekarri bezeroa itzuli eta jarraitu erantzun bakar bat ip route get erabiliz, iturburu-helbidea eta helmuga-helbidea eman zaizkiona, nukleoak aukeratuko lukeen bidea erakusten duena, eta gero ikusi paketeek benetan erabiltzen duten interfazea tcpdump -ni any port 1194 erabiliz. Zerbitzariaren egoera-fitxategiak, status direktibaren bidez minutuero gutxienez idazten denak, konektatutako bezeroen zerrenda eta bi noranzkoetarako byte-kontagailuak daramatza.
Irakurri kontagailu horiek elkarren aurka. Irten eta inoiz itzultzen ez den trafikoa bideratze-erantzuna da, ez handshake arazoa.