OpenVPN IP estatikoak bezero bakoitzeko: ifconfig-push, ez ipp.txt

ipp.txt fitxategiko lerro bat editatzekoak helbide bat erreserbatzen ari zaren sentsazioa ematen du, baina ez da hala. Fitxategi horrek, ifconfig-pool-persist bidez izendatuak, izen komun batek azken aldiz zein helbide zuen erregistratzen du, poolak berori itzuli ahal izan dezan komeni denean. Bertan ezerk ez du hurrengo konexioa zenbaki horretara lotzen.

Exekutatu beheko egiaztapenak hurrenez hurren. Bakoitzak mekanismoa baieztatzen du edo sarrera bat konpon zenezan esaten dizu.

Zertarako da iraunkortasun fitxategia

Fitxategia berrabiarazteen artean helbideak egonkor mantentzeko dago, eta horrek berriz konektatzea atseginagoa eta erregistroak irakurgarriagoak egiten ditu. Historial gisa irakurtzen eta historial gisa idazten da, eta esleipen bideak beste helbide bat aukeratzeko askatasuna gordetzen du pistak bat egiten ez duenean: beste pool bat, gatazkako esleipen bat edo poola bete ondoren iritsitako bezero bat. Horregatik eskuzko aldaketa bat perfektua izan daiteke fitxategian eta konexioan ezer ez aldatu. Hartu iraganeko erabakien cache gisa, ez politikaren iturri gisa.

Bezero jakin baterako helbide zehatza behar baduzu, dokumentatutako mekanismoa ifconfig-push da, eta bezero horren jabe den konfigurazioan dagokio.

Egiaztatu bezero zuzena hautatu dela

Esleipen esplizitua bezeroaren izen komunaren bidez bilatzen da, beraz identitate okerraren izenean dagoen fitxategia ez da inoiz irakurtzen. Egiaztatu zer hartzen duen zerbitzariak bezero horren izentzat, batez ere autentifikazioaren ondoren username-as-common-name horrek aldatzen duen tokian. Gero egiaztatu fitxategiaren izenak balio horrekin zehazki bat egiten duela, letra larri eta xeheak barne.

Pentsatu konkurrentzian hemen zauden bitartean. duplicate-cn onartzen bada, hainbat gailuk identitate bera aurkez dezakete, eta helbide finko batek ezin du denentzat bakarra izan. Erabaki helbide finkoak identitate horretarako aldi bereko saioak ukatzeko balio duen, bi baldintza horiek ezin baitira aldi berean bete.

Egiaztatu zenbakiek topologiarekin bat egiten dutela

Argumentuen esanahia tunelaren topologiaren araberakoa da, eta hemen egiten du kalterik handiena kopiatutako adibide batek. net30 antolamendu zaharrean bezero bakoitzak lau helbideko bloke bat hartzen du, beraz pushek helbide pare bat ematen du. Azpisare topologian bezeroak helbide bat eta poolaren maskara jasotzen ditu, eta parearen forma okerra da. Irakurri topologia exekuzioan dagoen konfiguraziotik lerroa idatzi aurretik.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Egiaztatu helbidea hura eduki dezakeen beste guztiaren aurka: beste esleipen esplizitu bat, pool dinamikoaren tartea eta ostalari finkoa suposatzen duen edozein bide estatiko. Poolarekin gainjartzen den helbidea poolak beste norbaiti eman arte funtzionatuko du, eta hutsegite hori ausazkoa dirudi.

Egiaztatu emaitza konexio berri batean

Lehendik dagoen saio batek eman zioten helbidea mantentzen du, beraz proba esanguratsu bakarra konexio berri bat da. Deskonektatu bezeroa, konektatu berriro eta irakurri benetan jaso zuen helbidea berarekin iritsitako bideekin batera. Helbidea oraindik dinamikoa bada, esleipena ez da aplikatu, eta hurrengo urratsa konfigurazioaren bilaketa da, ez historia fitxategiaren beste aldaketa bat.

Eduki frogak elkarrekin: bezeroaren izena, bat egin zuen fitxategia, esleitutako helbidea eta nondik etorri zen poola.

Azkenik, tunelaren helbide finkoa ez da gailuaren kredentziala. Helbide planean leku bat adierazten du, eta autentifikazioa ziurtagirian eta kontuan oinarritzen da oraindik. Biak nahasteak helbide gatazka inork idatzi ez zuen segurtasun suposizio bihurtzen du.