Statiese OpenVPN-kliëntadresse agter OPNsense

Name het adresse nodig wat nie beweeg nie, en OpenVPN se poel-lêer maak ’n adres net klewerig. Verloor daardie lêer, of heruitreik ’n sertifikaat onder ’n ander algemene naam, en die terugkerende kliënt beland elders in die poel terwyl sy DNS-rekord steeds na die ou adres wys. Die blywende antwoord is ’n kliëntspesifieke oorheersing wat die adres vaspen, plus ’n wyer tonnelnetwerk sodat vasgepen adresse buite die dinamiese reeks lê. Die rekenkunde agter daardie verbreding is waar die meeste verwarring lê.

OPNsense hou daardie oorheersings in die bediener se kliëntspesifieke instellings, gesleutel op die sertifikaat se algemene naam, wat die algemene naam deel van die adresplan maak.

’n Klewerige lease is nie ’n statiese adres nie

Die poel-lêer skryf adres-tot-kliënt-kaarte en gee dit terug wanneer ’n bekende kliënt weer koppel. Dit is gerief eerder as ’n kontrak: die lêer kan hergenereer word, die kaart verdwyn wanneer die kliënt se identiteit verander, en twee bedieners wat ’n poel deel sal dit nie eens wees nie. ’n Kliëntspesifieke oorheersing werk anders, want die adres kom uit konfigurasie eerder as uit geskiedenis. Dit oorleef ook ’n herbegin en ’n herinstallering van die toestel, mits die oorheersing saam met die res van die konfigurasie gerugsteun word.

Die dinamiese alternatief, om die VPN met ’n kliëntkoppel-skrip en dinamiese opdaterings in DNS te koppel, werk en vereis ’n resolver wat opdaterings aanvaar plus ’n skrip by elke koppeling. Op ’n toestel is jy beperk tot die pakkette wat die verskaffer lewer, en dit is gewoonlik waar daardie plan stop.

Die /30-rekenkunde waarvan niemand hou nie

Onder die verstek net30-topologie kry elke kliënt sy eie /30: die eerste bruikbare adres gaan na die bedienerkant, die tweede na die kliënt. Oorheersings moet dus buite die bediener se dinamiese tonnelnetwerk lê, wat beteken dat daardie netwerk eers verbreed moet word. ’n Bediener op 10.8.0.0/24 kan na 10.8.0.0/23 skuif en die helfte van die ou reeks vir dinamiese kliënte laat en die ander helfte vir oorheersings. Voeg die oorspronklike /24 as ’n bykomende IPv4-plaaslike netwerk by sodat verkeer na beide helftes in die tonnel ingaan.

Elke oorheersingsadres moet op ’n /30-grens val, so die laaste oktet is ’n veelvoud van vier. ’n /30 by 10.8.1.0 gee die kliënt 10.8.1.2, en dit is die adres wat die DNS-rekord dra. Om eerder 10.8.1.3 te kies lewer ’n kliënt wat koppel en nie verkeer kan deurlaat nie, want die adres behoort aan ’n subnet wat die topologie nooit aan hom toegewys het nie.

Die plan is makliker om te hou as oorheersings van die bokant van die verbreede reeks af ondertoe toegeken word, sodat die dinamiese poel in vrye ruimte uitbrei eerder as rondom vaste eilande.

Plaaslike netwerke en die sone wat kliënte navraag

Kliënt-tot-kliënt-verkeer benodig sy eie toestemming. Die bediener se IPv4-plaaslike netwerke-lys moet beide helftes van die reeks insluit, dinamies en staties; sonder dit aanvaar die bediener ’n pakket van een kliënt en het geen beleid wat dit na ’n ander deurlaat nie. Die simptoom lees soos ’n DNS-fout, want die naam los op en die verbinding faal steeds. Kontroleer terselfdertyd die kliënt-tot-kliënt-instelling, want ’n plaaslike-netwerk-inskrywing alleen aktiveer nie deurstiuring tussen eweknieë nie.

Publiseer die rekords in die sone waarna afgeleë kliënte werklik navraag doen. ’n Rekord in ’n sone wat net deur die LAN-resolver bedien word, is onsigbaar vir ’n kliënt wie se gestuurde resolver elders wys, en om meer rekords by die verkeerde sone te voeg maak dit nooit reg nie. Bevestig die gestuurde DNS-opsie en die soekdomein voordat jy enigiets byvoeg.

Wat om op ’n nuwe verbinding na te gaan

Koppel die kliënt weer en bevestig dat die toegewysde adres by sy oorheersing pas voordat jy enigiets anders toets. Los die naam dan op vanaf ’n tweede kliënt en koppel per naam aan die diens, wat die DNS-rekord, die roete en die vuurmuur saam uittoets. Bevestig die antwoordpad aan die bedienerkant, want ’n naam wat oplos terwyl die diens onbereikbaar bly, is ’n roeterings- of beleidsprobleem eerder as ’n naamprobleem. Hou die oorheersingstabel langs die sertifikaatlys sodat albei saam hersien word.

’n Sertifikaat wat onder ’n ander algemene naam heruitgereik word, pas nie meer by sy oorheersing nie en stuur die kliënt terug na die dinamiese poel. Verwag dit ná enige identiteitsverandering.