Dynamyske klanten ferbine en routing wurket goed, mar de iene klant mei in fêst adres berikt de tsjinner hielendal net. Der is neat yn ’e brânmuorre feroare, en de CCD-rige sjocht der leauwensweardich út. De gewoane oarsaak is in twadde argumint skreaun foar in oare TUN-topology as dy’t de tsjinner rint. De flater is stil: de klant komt omheech mei in adres en de tsjinner akseptearret de ferbining, mar dochs giet der gjin ferkear oer.

Under net30 is dat fjild in peeradres; under subnet is it in subnetmasker. De twa foarmen binne alternativen, nea in folchoarder.

De twa foarmen, njonken elkoar

Yn in tradisjonele net30-ynset hat elke klant in /30-blok: in netwurkadres, twa brûkbere adressen en in broadcastadres. ifconfig-push nimt it klantadres en it peeradres, en de peer is it oare brûkbere adres yn itselde blok, brûkt troch de tsjinnerkant fan ’e punt-nei-punt-ferbining.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

Under topology subnet dielt de klant ien subnet mei de tsjinner, en deselde rjochtline nimt in adres en in subnetmasker. It eigen adres fan ’e tsjinner komt fan ’e server-rjochtline, net fan it twadde fjild. It mingen fan ’e foarmen makket in klant dy’t tinkt dat er op in punt-nei-punt-ferbining sit, wylst de tsjinner him as subnethost routet, of oarsom. Dêrom mei in subnetmasker nea mei net30 pearre wurde.

Beide rigels yn it blok binne inkele rigels foar in CCD-bestân. Elke klant krijt krekt ien fan har.

Lês de topology dy’t de tsjinner eins rint

Lês de rinnende konfiguraasje ynstee fan in pakketstandert, om’t de topology jierren lyn ynsteld wêze kin en foarút kopiearre. Siket topology subnet of it ûntbrekken dêrfan, kontrolearje dan hoe’t de server-rige adressen tawiist. In konfiguraasje dy’t nea topology neamt is net itselde as ien dy’t subnet ynstelt.

Lês dan de ynstellingen dy’t de klant krigen hat. It adres, masker en peer dat er rapportearret fertelle jo hokker ynterpretaasje de tsjinner tapast hat.

Hâld it fêste adres bûten de dynamyske pool

In fêst adres moat bûten de dynamyske pool lizze, oars kinne twa klanten itselde adres krije. Mei subnet-topology ûnderdrukt nopool op ’e server-rige de automatyske pool, en in eksplisite ifconfig-pool-berik definiearret wat dynamyske klanten krije.

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

De tsjinner nimt 10.99.0.1 foar himsels, en it fêste klantadres leit bûten it berik fan ’e pool. It CCD-bestân wurdt neamd nei de effektive klantidentiteit, net nei de namme fan it profylbestân, en it hat gjin ekstra ekstinsje. As username-as-common-name aktyf is, is de autentisearre brûkersnamme de identiteit dy’t oerienkomme moat. Twa apparaten dy’t ien identiteit diele, diele ek it fêste adres, wat in beliedsprobleem is en gjin routingprobleem.

Ferifiearje de tawiizing dy’t de klant eins krigen hat

Ferbine de bedoelde klant opnij en befestigje hokker CCD-bestân selektearre waard foardat jo eat oars kontrolearje. Ferifiearje dan it adres, masker of peer, en de rûte werom nei de tsjinner. In klant dy’t in peeradres sjen lit yn in subnet-ynset brûkt noch altyd de ferkearde foarm.

It feroarjen fan topology beynfloedet elke klant en elke oerskriuwing, behannelje it dus as in migraasje en net as in reparaasje fan ien klant. It korrizjearjen fan ’e statyske rigel om oerien te kommen mei de topology dy’t al brûkt wurdt is meastentiids de lytsere feroaring. server-options-referinsje dokumintearret de helper en de klientspesifike oerskriuwingen.

Relatearre artikelen