Dy probleme emrash shfaqen pothuajse në çdo portë të vogël OpenVPN. Nuk arrini një laptop të lidhur me emrin në certifikatën e tij, dhe shërbimet pas tunelit nuk kanë fare emra. Duken si një problem dhe kërkojnë trajtim të kundërt, sepse një adresë lëviz me çdo sesion dhe tjetra jo. Vendosni çfarë lloj emri po shtoni përpara se të modifikoni ndonjë gjë.

Vendosni për çdo emër, jo për çdo portë

Testi është i thjeshtë: a ndryshon kjo adresë kur një klient rilidhet? Nëse po, emri duhet të gjenerohet nga sesioni VPN. Nëse jo, i përket një zëri statik që mund ta lexoni dhe rishikoni.

Name kindSource of truthWhere it lives
Connected clientThe address OpenVPN just assignedGenerated hosts file, rewritten per session
Service behind the tunnelA fixed address you choseStatic address= drop-in
Anything with a certificate nameThe certificate, not the poolEither, but the name must match the certificate

Përzierja e tyre është dështimi i zakonshëm. Një shërbim i fiksuar në skedarin e gjeneruar zhduket herën e parë që skripti e rishkruan, dhe një klient i shkruar në një zë statik tregon atë që e kishte atë adresë i fundit. Të dyja gabimet mbeten të padukshme derisa një emër të zgjidhet në makinën e gabuar. Deri atëherë, ai që korrigjon supozon se DNS-i është prishur dhe jo skedari.

Rruga dinamike: learn-address dhe pishina

OpenVPN e njeh caktimin, ndaj lëreni t'ju thotë. Këto opsione të serverit e bëjnë caktimin të qëndrueshëm dhe të skriptueshëm:

client-config-dir /etc/openvpn/ccd
ifconfig-pool-persist /etc/openvpn/ip-pool 60
script-security 2
learn-address /etc/openvpn/learn-address.sh

learn-address ekzekuton skriptin tuaj sa herë shtohet, përditësohet ose fshihet një adresë, dhe kalon operacionin, adresën dhe emrin e përbashkët. Një skript minimal shton një rresht për çdo klient dhe e heq atë kur fshihet:

#!/bin/sh
HOSTS=/etc/openvpn/hosts.lan
case "$1" in
  add|update) echo "$2 $3" >> "$HOSTS" ;;
  delete)     sed -i "/^$2 /d" "$HOSTS" ;;
esac
kill -HUP $(cat /var/run/dnsmasq.pid)

Në një pajisje tun argumenti i dytë është adresa e tunelit të klientit, kështu që rreshti mund të përdoret drejtpërdrejt. Në një pajisje tap OpenVPN kalon në vend të kësaj adresën MAC të klientit, sepse një segment tap mund të mbajë edhe protokolle të tjera përveç IPv4, dhe atëherë duhet ta kërkoni adresën në skedarin e pishinës me emrin e përbashkët përpara se të shkruani ndonjë gjë.

Jini të qartë se çfarë është skedari i gjeneruar: një fotografi e kush është i lidhur tani. Emrat zhduken kur shkëputet, gjë që është pikërisht ajo që dëshironi për laptopët që lëvizin mes rrjeteve dhe pikërisht ajo që nuk dëshironi për një server që rri ndezur gjithë natën.

Rruga statike: address= dhe zgjerimi i domenit

Drejtojeni dnsmasq drejt skedarit të gjeneruar në vend të skedarit hosts të sistemit, dhe jepini një domen që emrat e shkurtër të zgjerohen në emra plotësisht të kualifikuar:

domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfaces

Kur domain është vendosur, një rresht si 10.8.0.6 alice përgjigjet si për alice ashtu edhe për alice.corp.example. Mbani listen-address vetëm në portën e tunelit dhe loopback, sepse një zgjidhës i publikuar aksidentalisht në ndërfaqen LAN është një shërbim që nuk kishit ndërmend ta ofroni.

Shërbimet që nuk vijnë kurrë nga pishina marrin zërat e tyre. Vendosini në një skedar drop-in të veçantë në drejtorinë e konfigurimit të shpërndarjes, që një përditësim pakete të mos mund t'i mbishkruajë:

address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5

Dorëzoni zgjidhësin ose nuk ndodh asgjë

Një zgjidhës që askush nuk e pyet nuk ndryshon asgjë. Serveri duhet ta shpallë atë:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Klientët Windows i zbatojnë vetë të dyja opsionet. Shumica e klientëve Linux nuk e bëjnë: atyre u duhet një integrim i mbështetur i zgjidhësit, si grepja update-resolv-conf e shpërndarjes ose trajtimi i DNS-së nga NetworkManager, ose një domen kërkimi dhe nameserver të vendosur me dorë. Kontrolloni zgjidhësin aktual të klientit në vend që të supozoni se push-i u respektua, sepse një push i injoruar duket saktësisht si një server që nuk përgjigjet.

Verifikoni në tre shtresa

Pyetni fillimisht serverin drejtpërdrejt, pastaj një klient, pastaj aplikacionin:

dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.example

Nëse pyetjet e drejtpërdrejta përgjigjen dhe aplikacioni jo, faji është në dorëzimin te klienti dhe jo në zonë. Nëse emri zgjidhet dhe lidhja ende dështon, emri është në rregull dhe gjëja tjetër për t'u parë është rruga ose firewalls.

Shkruani dy kategoritë pranë konfigurimit: cilët emra gjenerohen, cilët janë të fiksuar dhe me cilin certifikatë duhet të përputhet secili. Personi tjetër që shton një server do të kopjojë modelin e parë që gjen.

Artikuj të ngjashëm