Statikaj OpenVPN-klientaj adresoj malantaŭ OPNsense
Pula dosiero faras adreson glueca, ne daŭra. Fiksu klientajn adresojn per anstataŭigoj, larĝigu la tunelan amplekson por la /30-aritmetiko, poste publikigu ilin.
Nomoj bezonas adresojn, kiuj ne moviĝas, kaj la pula dosiero de OpenVPN nur faras adreson glueca. Perdu tiun dosieron, aŭ reeldonu atestilon sub alia komuna nomo, kaj la revenanta kliento surteriĝos aliloke en la pulo, dum ĝia DNS-rikordo ankoraŭ montras al la malnova adreso. La daŭra respondo estas klient-specifa anstataŭigo, kiu fiksas la adreson, plus pli larĝa tunela reto, por ke fiksitaj adresoj staru ekster la dinamika amplekso. La aritmetiko malantaŭ tiu larĝigo estas kie loĝas la plej granda parto de la konfuzo.
OPNsense tenas tiujn anstataŭigojn en la klient-specifaj agordoj de la servilo, ŝlositaj per la komuna nomo de la atestilo, kio faras la komunan nomon parto de la adresa plano.
Glueca luo ne estas statika adreso
La pula dosiero skribas mapojn de adreso al kliento kaj redonas ilin kiam konata kliento rekonektiĝas. Tio estas oportuneco, ne kontrakto: la dosiero povas esti regenerita, la mapo malaperas kiam la identeco de la kliento ŝanĝiĝas, kaj du serviloj kunhavantaj pulon ne konsentos pri ĝi. Klient-specifa anstataŭigo funkcias alie, ĉar la adreso venas el agordo anstataŭ el historio. Ĝi ankaŭ postvivas restartigon kaj reinstalon de la aparato, kondiĉe ke la anstataŭigo estas savkopiita kun la resto de la agordo.
La dinamika alternativo, ligi la VPN-on al DNS per klient-liga skripto kaj dinamikaj ĝisdatigoj, funkcias kaj postulas solvilon, kiu akceptas ĝisdatigojn, plus skripton ĉe ĉiu ligo. Sur aparato vi estas limigita al la pakoj, kiujn la vendisto liveras, kaj kutime ĝuste tie tiu plano haltas.
La /30-aritmetiko, kiun neniu ĝuas
Sub la defaŭlta topologio net30, ĉiu kliento ricevas sian propran /30: la unua uzebla adreso iras al la servila flanko, la dua al la kliento. Anstataŭigoj do devas stari ekster la dinamika tunela reto de la servilo, kio signifas unue larĝigi tiun reton. Servilo sur 10.8.0.0/24 povas moviĝi al 10.8.0.0/23, lasante unu duonon de la malnova amplekso por dinamikaj klientoj kaj la alian duonon por anstataŭigoj. Aldonu la originalan /24 kiel plian lokan IPv4-reton, por ke trafiko al ambaŭ duonoj eniru la tunelon.
Ĉiu anstataŭiga adreso devas fali sur limon /30, do la lasta okjeto estas multoblo de kvar. /30 ĉe 10.8.1.0 donas al la kliento 10.8.1.2, kaj tiu estas la adreso, kiun portas la DNS-rikordo. Elekti anstataŭe 10.8.1.3 produktas klienton, kiu konektiĝas kaj ne povas trapasi trafikon, ĉar la adreso apartenas al subreto, kiun la topologio neniam atribuis al ĝi.
La plano estas pli facile tenebla se anstataŭigoj estas asignitaj de la supro de la larĝigita amplekso malsupren, por ke la dinamika pulo etendiĝu en liberan spacon anstataŭ ĉirkaŭ fiksaj insuloj.
Lokaj retoj kaj la zono, kiun klientoj pridemandas
Klient-al-klienta trafiko bezonas propran permeson. La listo de lokaj IPv4-retoj de la servilo devas inkluzivi ambaŭ duonojn de la amplekso, dinamikan kaj statikan; sen ĝi la servilo akceptas paketon de unu kliento kaj havas neniun politikon permesantan ĝin al alia. La simptomo legiĝas kiel DNS-fiasko, ĉar la nomo solviĝas kaj la konekto ankoraŭ malsukcesas. Kontrolu samtempe la agordon klient-al-klient, ĉar sola rikordo de loka reto ne ebligas plusendadon inter samranguloj.
Publikigu la rikordojn en la zono, kiun malproksimaj klientoj efektive pridemandas. Rikordo en zono servata nur de la LAN-solvilo estas nevidebla por kliento, kies puŝita solvilo montras aliloken, kaj aldoni pliajn rikordojn al la malĝusta zono neniam riparas tion. Konfirmu la puŝitan DNS-opcion kaj la serĉan domajnon antaŭ ol aldoni ion ajn.
Kion kontroli ĉe nova konekto
Rekonektu la klienton kaj konfirmu, ke la asignita adreso kongruas kun ĝia anstataŭigo antaŭ ol testi ion ajn alian. Poste solvu la nomon de dua kliento kaj konektiĝu al la servo per la nomo, kio ekzercas la DNS-rikordon, la itineron kaj la fajroŝirmilon kune. Konfirmu la respondan vojon ĉe la servila flanko, ĉar nomo, kiu solviĝas dum la servo restas neatingebla, estas itinerada aŭ politika problemo, ne nomada. Tenu la anstataŭigan tabelon apud la atestila listo, por ke ambaŭ estu reviziitaj kune.
Atestilo reeldonita sub alia komuna nomo ĉesas kongrui kun sia anstataŭigo kaj resendas la klienton al la dinamika pulo. Atendu tion post ĉiu identeca ŝanĝo.