Prefix de sucursală IPv6: iroute-ipv6 sau route-ipv6 pe server?

Două directive cu un nume aproape identic apar în fiecare exemplu funcțional, iar copierea uneia fără cealaltă produce un tunel care pare corect și aruncă în tăcere prefixul sucursalei. Fac treburi diferite pe laturi diferite ale aceleiași granițe: una învață nucleul serverului unde locuiește un prefix, iar cealaltă îi spune lui OpenVPN care client autentificat îl transportă. Dacă ambele sunt corecte, prefixul curge; dacă doar una este corectă, pachetele au o rută dar nu au un proprietar.

Două directive, două treburi diferite

route-ipv6 este o instalare de rută obișnuită: serverul adaugă o rută în nucleu care îndreaptă prefixul spre interfața sa de tunel. iroute-ipv6 aparține unui context specific clientului și declară proprietatea internă, astfel încât daemonul știe că traficul pentru acel prefix trebuie trimis unui anumit client, nu peer-ului pe care o rută din nucleu îl numește din întâmplare.

Una privește tabela de forwardare a nucleului, cealaltă modelul intern de rutare al daemonului. Ținerea lor separate explică de ce o configurație care pare completă poate totuși arunca prefixul. Explică și de ce aceeași rețea apare de două ori în fiecare exemplu funcțional. Niciuna dintre cele două linii nu este redundantă.

În configurația tradițională în userspace ambele sunt necesare și se completează reciproc. O rută doar în nucleu lasă daemonul incapabil să aleagă un peer. Un iroute singur lasă nucleul fără o cale către tunel. De aici vine și cea mai mare parte a confuziei despre fișierele per client: fișierul nu este o intrare în tabela de rutare, iar intrarea de rută nu este o declarație de proprietate.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Unde merge fiecare

Ruta merge în configurația administrată a serverului, unde se aplică pentru acel proces de server. Irouta merge în fișierul specific clientului, numit după identitatea autentificată a echipamentului sucursalei.

Un nume de fișier care nu corespunde identității efective nu este niciodată citit, iar simptomul este identic cu un iroute lipsă. Verifică identitatea pe care serverul a autentificat-o, apoi verifică numele fișierului caracter cu caracter.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Ține pool-ul și prefixul sucursalei separate, pentru că suprapunerea lor creează un puzzle pe care nicio directivă nu îl poate rezolva.

De ce are nevoie un alt client

Un al doilea client care trebuie să ajungă la acea sucursală are nevoie de un anunț, nu de proprietate. Împinge prefixul către clienții pe care îi vrei, în contextul de client sau de grup care se potrivește configurației tale.

Nu îl trimite sucursalei înseși, pentru că acel dispozitiv are deja prefixul ca rețea conectată.

Trimiterea lui către toți este o alegere cu consecințe: fiecare client crede atunci că sucursala este accesibilă prin tunel, inclusiv clienții cărora nu ai vrut niciodată să le acorzi acel acces. Anunțarea este în practică o decizie de acces, chiar dacă directiva arată ca o lucrare de instalații. referința pentru opțiunile serverului documentează iroute-ipv6 ca proprietate specifică clientului, iar aceasta este distincția care merită păstrată.

Calea de întoarcere pe echipamentul sucursalei

Proprietatea ajută doar dacă sucursala forwardează pachete și LAN-ul ei știe cum să răspundă. Activează forwardarea IPv6 pe echipamentul sucursalei și confirmă că gazdele din LAN-ul ei trimit traficul pentru pool-ul VPN înapoi spre sucursală, nu spre o rută implicită care nu cunoaște pool-ul.

Acea cale de întoarcere este echivalentul IPv6 al problemei rutei lipsă pe care oamenii o întâlnesc cu IPv4.

Verifică-o de la o gazdă din LAN cu o căutare pentru adresa pool-ului VPN, nu de la sucursala însăși. O căutare făcută pe router răspunde la o altă întrebare decât cea a utilizatorilor tăi, iar cele două nu sunt de acord destul de des încât să merite comanda suplimentară.

Când perechea tot nu este suficientă

Unele implementări nu folosesc deloc această cale. Calea de date a nucleului și serverele administrate de produs au propriul tratament de rute acceptat, iar un exemplu în userspace poate să nu se traducă direct.

Confirmă ce cale de date folosește build-ul tău înainte de a copia directive dintr-un tutorial scris pentru cealaltă.

În final, ține minte domeniul adreselor: un prefix local unic precum fd00:7a::/64 este privat prin proiectare și nu spune nimic despre accesibilitatea IPv6 publică. Tratează-l ca acces intern și ține ieșirea la internet o chestiune separată, cu propria politică.