Un hub OpenVPN, trei LAN-uri: planul de adrese și fișierele iroute

Trei LAN-uri private se pot întâlni pe un singur hub fără ca vreo locație să cunoască structura internă a celorlalte, iar întregul proiect se sprijină pe patru decizii scurte de configurare. Ceea ce îl face să funcționeze nu este o funcție exotică de protocol, ci un plan de adrese pe care nimeni nu trebuie să-l ghicească, plus rute per client care îi spun hub-ului ce filială deține ce prefix. Dacă oricare dintre ele este greșit, tunelul tot se ridică, și exact asta face defecțiunea confuză.

Parcurge pașii în ordine. Fiecare depinde de planul pasului anterior și niciunul nu necesită o nouă autoritate de certificare.

Începe cu un plan pe care nimeni nu trebuie să-l ghicească

Notează patru prefixe disjuncte înainte de a atinge un fișier de configurare: LAN-ul hub-ului însuși, LAN-ul fiecărei filiale și pool-ul oferit clienților nomazi. Disjuncția este ceea ce menține tot restul simplu, pentru că intervalele suprapuse transformă rutarea într-un puzzle al celei mai lungi potriviri pe care nicio configurare per client nu îl repară. Apoi confirmă ce mașină este gateway-ul implicit pentru fiecare LAN, deoarece un router de filială care nu este gateway-ul propriului LAN trebuie să instaleze rutele la distanță cu totul în altă parte. În final, fixează numele autentificate care identifică fiecare filială, pentru că acele nume sunt cheile după care se caută fișierele per client.

Un plan ilustrativ ține pool-ul departe de cele trei LAN-uri. Al tău va fi diferit, iar singura regulă dură este că nici două intervale nu se suprapun.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Spune kernel-ului hub-ului unde sunt filialele

Hub-ul are nevoie de două informații per filială: o rută de kernel care trimite prefixul în dispozitivul de tunel și o intrare iroute care îi spune procesului OpenVPN ce client o deține. Doar ruta de kernel livrează pachetele în tunel și se oprește acolo, pentru că daemonul încă trebuie să decidă ce peer să le primească. Doar intrarea iroute lasă acele pachete în kernel fără o rută de urmat. Ambele linii aparțin configurației pe care daemonul o încarcă efectiv, iar asta merită verificat înainte de a depana orice altceva.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Ține client-to-client oprit atunci când kernel-ul trebuie să fie punctul de aplicare a regulilor. Acea opțiune retransmite traficul între peer-i în interiorul daemonului, ceea ce este comod și înseamnă și că regulile tale de forwarding nu văd niciodată fluxul. Tot ce urmează presupune că kernel-ul vede fiecare pachet între filiale.

Dă fiecărei filiale rutele de care are nevoie

Fiecare filială are nevoie de rute către celelalte filiale și către LAN-ul hub-ului și nu are nevoie de una pentru propriul LAN conectat. Împinge prefixele la distanță din hub în loc să le lipești în fiecare router, astfel încât o a patra locație mai târziu să însemne un singur fișier nou per client în loc de patru modificări. Fișierul per client conține și linia iroute, care ține proprietatea și anunțul în același loc. Fă directorul și fișierele lui lizibile conform modelului de privilegii al serverului, altfel căutarea eșuează fără mesaj.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

O a patra locație urmează același model: un nume autentificat distinct, un prefix deținut, o rută de kernel pe hub, o intrare iroute și anunțuri doar către locațiile autorizate să o atingă.

Testează în ambele direcții înainte de a declara gata

Activează forwarding-ul IPv4 pe toate cele trei routere, apoi confirmă că firewall-ul permite fluxurile dorite în ambele direcții, pentru că un test unidirecțional trece cu o cale de întoarcere ruptă mai des decât se așteaptă cineva. Între locații nu este nevoie de traducere a adresei sursă, iar păstrarea sursei originale este exact ceea ce permite fiecărei filiale să aplice propria politică unei cereri.

Testează de la un host dintr-un LAN de filială la un serviciu din altul, apoi inversează direcția, apoi testează de la o filială la LAN-ul hub-ului. Acele trei rezultate sunt dovezi diferite și niciunul nu le implică pe celelalte. Dacă un router de filială nu este gateway-ul implicit al propriului LAN, instalează prefixele la distanță pe gateway-ul real și include și pool-ul când clienții tunelului trebuie să înceapă conexiuni în acel LAN.

Înregistrează planul, fișierele per client și regulile de firewall ca un singur document, pentru că următoarea adăugare de locație va fi judecată după ele.

Proiectul se ține împreună pentru că fiecare strat are o singură sarcină: planul menține prefixele unice, ruta de kernel mută pachetele, iroute numește proprietarul, iar firewall-ul decide ce este permis. Când ceva se strică, acea listă este și ordinea de verificare.