Staattiset OpenVPN-asiakasosoitteet OPNsensen takana
Pool-tiedosto tekee osoitteesta tahmean, ei pysyvän. Kiinnitä asiakasosoitteet ohituksilla, laajenna tunnelialuetta /30-laskentaa varten ja julkaise ne.
Nimet tarvitsevat osoitteita, jotka eivät liiku, ja OpenVPN:n pool-tiedosto tekee osoitteesta vain tahmean. Menetä se tiedosto tai myönnä varmenne uudelleen toisella yleisnimellä, niin palaava asiakas päätyy muualle pooliin, kun taas sen DNS-tietue osoittaa edelleen vanhaan osoitteeseen. Kestävä vastaus on asiakaskohtainen ohitus, joka kiinnittää osoitteen, sekä laajempi tunneliverkko, jotta kiinnitetyt osoitteet ovat dynaamisen alueen ulkopuolella. Laajennuksen takana oleva laskenta on paikka, jossa suurin osa sekaannuksesta asuu.
OPNsense pitää nämä ohitukset palvelimen asiakaskohtaisissa asetuksissa, avaimena varmenteen yleisnimi, mikä tekee yleisnimestä osan osoitesuunnitelmaa.
Tahmea vuokra ei ole staattinen osoite
Pool-tiedosto kirjoittaa osoitteen ja asiakkaan väliset kuvaukset ja palauttaa ne, kun tunnettu asiakas yhdistää uudelleen. Se on mukavuutta, ei sopimus: tiedosto voidaan luoda uudelleen, kuvaus katoaa, kun asiakkaan identiteetti muuttuu, eivätkä kaksi poolia jakavaa palvelinta ole siitä samaa mieltä. Asiakaskohtainen ohitus toimii eri tavalla, koska osoite tulee kokoonpanosta eikä historiasta. Se kestää myös uudelleenkäynnistyksen ja laitteen uudelleenasennuksen, kunhan ohitus varmuuskopioidaan muun kokoonpanon mukana.
Dynaaminen vaihtoehto, VPN:n kytkeminen DNS:ään asiakasyhteysskriptillä ja dynaamisilla päivityksillä, toimii ja vaatii resolverin, joka hyväksyy päivitykset, sekä skriptin joka yhteydellä. Laitteessa olet rajoittunut valmistajan toimittamiin paketteihin, ja yleensä suunnitelma pysähtyy siihen.
/30-laskenta, josta kukaan ei nauti
Oletusarvoisessa net30-topologiassa jokainen asiakas saa oman /30:nsä: ensimmäinen käyttökelpoinen osoite menee palvelimen puolelle, toinen asiakkaalle. Ohitusten on siksi oltava palvelimen dynaamisen tunneliverkon ulkopuolella, mikä tarkoittaa, että verkkoa on ensin laajennettava. Palvelin osoitteessa 10.8.0.0/24 voi siirtyä osoitteeseen 10.8.0.0/23, jolloin puolet vanhasta alueesta jää dynaamisille asiakkaille ja toinen puoli ohituksille. Lisää alkuperäinen /24 ylimääräiseksi paikalliseksi IPv4-verkoksi, jotta liikenne molempiin puoliin kulkee tunneliin.
Jokaisen ohitusosoitteen on osuttava /30-rajalle, joten viimeinen oktetti on neljän monikerta. /30 osoitteessa 10.8.1.0 antaa asiakkaalle 10.8.1.2, ja se on osoite, jota DNS-tietue kantaa. Jos valitset sen sijaan 10.8.1.3:n, saat asiakkaan, joka yhdistää eikä pysty välittämään liikennettä, koska osoite kuuluu aliverkkoon, jota topologia ei koskaan osoittanut sille.
Suunnitelmaa on helpompi pitää, jos ohitukset jaetaan laajennetun alueen yläpäästä alaspäin, jolloin dynaaminen pooli laajenee vapaaseen tilaan eikä kiinteiden saarten ympärille.
Paikallisverkot ja vyöhyke, jota asiakkaat kysyvät
Asiakkaiden välinen liikenne tarvitsee oman lupansa. Palvelimen IPv4-paikallisverkkojen luetteloon on sisällyttävä alueen molemmat puolet, dynaaminen ja staattinen; ilman sitä palvelin hyväksyy paketin yhdeltä asiakkaalta eikä sillä ole käytäntöä, joka päästäisi sen toiselle. Oire näyttää DNS-vialta, koska nimi ratkeaa ja yhteys silti epäonnistuu. Tarkista samalla asiakkaiden välinen asetus, sillä pelkkä paikallisverkon merkintä ei mahdollista välitystä vertaisten välillä.
Julkaise tietueet vyöhykkeellä, jota etäasiakkaat todella kysyvät. Tietue vyöhykkeellä, jota vain lähiverkon resolveri palvelee, on näkymätön asiakkaalle, jonka työnnetty resolveri osoittaa muualle, eikä lisätietueiden lisääminen väärälle vyöhykkeelle korjaa sitä koskaan. Vahvista työnnetty DNS-asetus ja hakutoimialue ennen kuin lisäät mitään.
Mitä uudesta yhteydestä tarkistetaan
Yhdistä asiakas uudelleen ja vahvista, että määritetty osoite vastaa sen ohitusta, ennen kuin testaat mitään muuta. Ratkaise sitten nimi toiselta asiakkaalta ja yhdistä palveluun nimellä, mikä koettelee DNS-tietuetta, reittiä ja palomuuria yhdessä. Vahvista vastauspolku palvelimen puolella, sillä nimi, joka ratkeaa samalla kun palvelu pysyy tavoittamattomana, on reititys- tai käytäntöongelma eikä nimeämisongelma. Pidä ohitustaulukko varmenneluettelon vieressä, jotta molemmat tarkistetaan yhdessä.
Toisella yleisnimellä uudelleen myönnetty varmenne lakkaa vastaamasta ohitustaan ja palauttaa asiakkaan dynaamiseen pooliin. Odota sitä jokaisen identiteettimuutoksen jälkeen.