Statiske OpenVPN-klientadresser bak OPNsense
Ei poolfil gjer ei adresse klebrig, ikkje permanent. Fest klientadresser med overstyringar, utvid tunnelområdet for /30-aritmetikken, og publiser dei deretter.
Namn treng adresser som ikkje flyttar seg, og poolfila til OpenVPN gjer berre ei adresse klebrig. Mistar du den fila, eller gjev ut eit sertifikat på nytt under eit anna vanleg namn, hamnar den tilbakevendande klienten ein annan stad i poolen medan DNS-oppføringa hans framleis peikar på den gamle adressa. Det varige svaret er ei klientspesifikk overstyring som festar adressa, pluss eit breiare tunnelnettverk slik at festa adresser ligg utanfor det dynamiske området. Aritmetikken bak den utvidinga er der det meste av forvirringa bur.
OPNsense held desse overstyringane i klientspesifikke innstillingar på serveren, nøkla på det vanlege namnet til sertifikatet, noko som gjer det vanlege namnet til ein del av adresseplanen.
Ein klebrig lease er ikkje ei statisk adresse
Poolfila skriv adresse-til-klient-tilknytingar og gjev dei tilbake når ein kjend klient koplar til på nytt. Det er komfort, ikkje ein kontrakt: fila kan genererast på nytt, tilknytinga forsvinn når identiteten til klienten endrar seg, og to serverar som deler ein pool blir ikkje samde om henne. Ei klientspesifikk overstyring verkar annleis, fordi adressa kjem frå konfigurasjonen i staden for frå historia. Ho overlever òg ein omstart og ein reinstallasjon av apparatet, føresett at overstyringa blir sikkerheitskopiert saman med resten av konfigurasjonen.
Det dynamiske alternativet, å kople VPN-en til DNS med eit klientkopling-skript og dynamiske oppdateringar, verkar og krev ein resolver som godtek oppdateringar, pluss eit skript ved kvar kopling. På eit apparat er du avgrensa til pakkane leverandøren sender, og det er vanlegvis der den planen stoppar.
/30-aritmetikken ingen likar
Under standardtopologien net30 får kvar klient sin eigen /30: den første brukbare adressa går til serversida, den andre til klienten. Overstyringar må derfor liggje utanfor det dynamiske tunnelnettverket til serveren, noko som tyder at nettverket først må utvidast. Ein server på 10.8.0.0/24 kan flyttast til 10.8.0.0/23 og late halvparten av det gamle området vere for dynamiske klientar og den andre halvparten for overstyringar. Legg til den opphavlege /24 som eit ekstra lokalt IPv4-nettverk slik at trafikk til begge halvdelar går inn i tunnelen.
Kvar overstyringsadresse må lande på ei /30-grense, så den siste oktetten er eit multiplum av fire. Ei /30 på 10.8.1.0 gjev klienten 10.8.1.2, og det er adressa DNS-oppføringa ber. Vel du i staden 10.8.1.3, får du ein klient som koplar til og ikkje kan sleppe gjennom trafikk, fordi adressa høyrer til eit subnett som topologien aldri tildelte henne.
Planen er lettare å halde om overstyringar blir tildelte frå toppen av det utvida området og nedover, slik at den dynamiske poolen utvidar seg i ledig plass i staden for rundt faste øyar.
Lokale nettverk og sona klientane spør
Klient-til-klient-trafikk treng si eiga løyve. Lista til serveren over lokale IPv4-nettverk må innehalde begge halvdelar av området, dynamisk og statisk; utan henne godtek serveren ein pakke frå ein klient og har inga policy som slepper han gjennom til ein annan. Symptomet les som ein DNS-feil, fordi namnet slår opp og koplinga likevel feilar. Sjekk klient-til-klient-innstillinga samstundes, sidan ei oppføring for lokalt nettverk åleine ikkje aktiverer vidaresending mellom likemenn.
Publiser oppføringane i sona eksterne klientar faktisk spør. Ei oppføring i ei sone som berre blir tent av LAN-resolveren, er usynleg for ein klient der den pusja resolveren peikar ein annan stad, og fleire oppføringar i feil sone reparerer det aldri. Stadfest det pusja DNS-alternativet og søkjedomenet før du legg til noko.
Kva du bør sjekke på ei ny kopling
Kople klienten til på nytt og stadfest at den tildelte adressa samsvarer med overstyringa før du testar noko anna. Slå deretter opp namnet frå ein annan klient og kople til tenesta ved namn, noko som prøver DNS-oppføringa, ruta og brannmuren saman. Stadfest svarvegen på serversida, sidan eit namn som slår opp medan tenesta blir verande utilgjengeleg, er eit rute- eller policyproblem og ikkje eit namneproblem. Hald overstyringstabellen ved sida av sertifikatlista slik at begge blir gjennomgått saman.
Eit sertifikat som blir gjeve ut på nytt under eit anna vanleg namn, sluttar å samsvare med overstyringa si og sender klienten tilbake til den dynamiske poolen. Vent det etter kvar identitetsendring.