Dinamiese kliënte verbind en roetebepaling werk fyn, maar die enkele kliënt met ’n vaste adres kan die bediener glad nie bereik nie. Niks in die vuurmuur het verander nie, en die CCD-lyn lyk geloofwaardig. Die gewone oorsaak is ’n tweede argument wat vir ’n ander TUN-topologie geskryf is as wat die bediener gebruik. Die fout is stil: die kliënt kom op met ’n adres en die bediener aanvaar die verbinding, maar tog kruis geen verkeer nie.

Onder net30 is daardie veld ’n peeradres; onder subnet is dit ’n netmask. Die twee vorme is alternatiewe, nooit ’n reeks nie.

Die twee vorme, langs mekaar

In ’n tradisionele net30-implementering besit elke kliënt ’n /30-blok: ’n netwerkadres, twee bruikbare adresse en ’n uitsendadres. ifconfig-push neem die kliëntadres en die peeradres, en die peer is die ander bruikbare adres in dieselfde blok, wat deur die bedienerskant van die punt-tot-punt-verbinding gebruik word.

# 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

Onder topology subnet deel die kliënt een subnet met die bediener, en dieselfde richtlijn neem ’n adres en ’n netmask. Die bediener se eie adres kom uit die server-richtlijn, nie uit die tweede veld nie. Die vermenging van die vorme lewer ’n kliënt wat glo dat hy op ’n punt-tot-punt-verbinding is, terwyl die bediener hom as ’n subnetgasheer roetebepaal, of andersom. Dit is waarom ’n netmask nooit met net30 gepaard mag gaan nie.

Albei lyne in die blok is enkele lyne vir ’n CCD-lêer. Een kliënt kry presies een van hulle.

Lees die topologie wat die bediener werklik gebruik

Lees die lopende konfigurasie eerder as ’n pakketstandaard, omdat die topologie jare ago vasgestel en oorgedra kon word. Soek topology subnet of sy afwesigheid, en kontrolleer dan hoe die server-lyn adresse toegewys. ’n Konfigurasie wat nooit topologie noem nie, is nie dieselfde as een wat subnet stel nie.

Lees dan die kliënt se ontvang instellings. Die adres, masker en peer wat dit rapporteer, sê jou watter interpretasie die bediener toegepas het.

Hou die vaste adres buite die dinamiese poel

’n Vaste adres moet buite die dinamiese poel sit, anders kan twee kliënte dieselfde adres kry. Met subnet-topologie onderdruk nopool op die server-lyn die outomatiese poel, en ’n eksplisiete ifconfig-pool-bereik bepaal wat dinamiese kliënte ontvang.

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

Die bediener neem 10.99.0.1 vir homself, en die vaste kliëntadres sit buite die poelbereik. Die CCD-lêer word na die effektiewe kliëntidentiteit genoem, nie na die profiellêernaam nie, en dit het geen ekstra uitbreiding nie. As username-as-common-name aktief is, is die geauthentikeerde gebruikernaam die identiteit wat moet pas. Twee toestelle wat een identiteit deel, deel ook die vaste adres, wat ’n beleidsprobleem eerder as ’n roetebepalingsprobleem is.

Verifieer die toewysing wat die kliënt werklik ontvang het

Herverbind die beoogde kliënt en bevestig watter CCD-lêer geselekteer was voordat jy enigiets anders kontrolleer. Verifieer dan die adres, masker of peer, en die roete terug na die bediener. ’n Kliënt wat ’n peeradres in ’n subnet-implementering wys, gebruik steeds die verkeerde vorm.

Die verandering van topologie beïnvloed elke kliënt en elke oorskrywing, so behandel dit as ’n migrasie eerder as ’n een-kliënt-reparasie. Die regstelling van die statiese lyn om te pas by die topologie wat reeds in gebruik is, is gewoonlik die kleiner verandering. Die verwysing na server-options dokumenteer die helper en die kliëntspesifieke oorskrywings.

Verwante artikels