Utilizator de gateway în Access Server: rutarea LAN-ului sucursalei unui client

Puteți face ping la adresa de tunel a unui client OpenVPN și totuși să nu ajungeți la niciun host din LAN-ul din spate. Access Server îi dă clientului o adresă din pool-ul VPN, iar acea adresă este tot ce serverul știe că deține. Prefixul sucursalei este un fapt separat care trebuie declarat, și chiar atunci sucursala are nevoie de un redirector, iar sediul de o cale de întoarcere. O rută scrisă în locul greșit nu schimbă nimic.

Două adrese, două revendicări de proprietate

Când un client se conectează, Access Server îi atribuie o adresă din pool-ul configurat, de exemplu 10.90.0.0/24. Acea atribuire este o închiriere pentru un singur host. Nimic nu spune că același client stă și în fața 10.60.0.0/24, iar serverul nu ghicește: un prefix LAN este accesibil printr-un client anume doar dacă administratorul îl declară.

De aceea o rută statică pe altă mașină nu ajută. Ruta spune trimite 10.60.0.0/24 la această adresă, dar dacă adresa aparține unui client nemarcat ca gateway, serverul nu are motiv să livreze pachetele acolo, iar stiva clientului le poate arunca. Declarația și ruta sunt două jumătăți ale aceluiași mecanism.

Ce instalează setarea de gateway

În Admin Web UI declarația este o proprietate de utilizator: activați Configure VPN gateway la utilizatorul conector și introduceți prefixul real în Network on the VPN client side. Utilizatorul se autentifică ca oricare altul, deci are nevoie de o politică de acreditări pentru un dispozitiv fără supraveghere, iar profilul de conectare automată este un secret.

Serverul tratează prefixul ca accesibil prin adresa din pool a clientului, iar rutarea din Access Controls decide ce se anunță celorlalți: rutele trimise clienților obișnuiți și regulile de acces din rețelele sediului către adresele și subrețelele clienților. Activați rutarea pentru rețelele care trebuie să ajungă la sucursală și păstrați lista scurtă.

O directivă în stil Community lipită într-un fișier generat nu participă la acest model. Produsul deține tabelul de rutare pe care îl trimite; o linie editată manual este suprascrisă sau ignorată.

Completați căile de întoarcere ale ambelor rețele

Plan concret: sediu 10.40.0.0/24, sucursală 10.60.0.0/24, pool VPN 10.90.0.0/24, iar Access Server accesibil la o adresă privată în partea sediului. Routerul sediului are nevoie de rute pentru prefixul sucursalei și pentru pool. Fără ele tunelul duce cererea și răspunsul iese prin gateway-ul implicit, ceea ce dă conexiunea pe jumătate deschisă.

În sucursală conectorul trebuie să redirecționeze pachetele care nu îi sunt adresate: redirecționare IP în sistemul de operare plus o permisiune limitată la interfețele tunelului și ale LAN-ului; în Linux este net.ipv4.ip_forward=1 cu regulile lanțului forward, în Windows este routing and remote access. Apoi hosturile au nevoie de o cale de întoarcere: fie conectorul este gateway-ul implicit, fie gateway-ul existent poartă rute specifice.

Tabelul de rutare al conectorului nu reconfigura fiecare host din LAN-ul sucursalei. Dacă hosturile indică alt router, rutele de întoarcere aparțin acolo, iar acesta trebuie să accepte că adresa sursă văzută nu este un vecin din subrețeaua locală.

Citiți o defecțiune ca pe o cale

Testați într-o ordine fixă. întâi un serviciu permis de la Access Server către un host din sucursală, apoi același serviciu dintr-un host obișnuit al sediului, apoi sensul invers dacă politica permite. Dacă primul trece și al doilea eșuează, problema sunt rutele trimise sau regulile de acces. Dacă ambele trec dar nu vin răspunsuri, verificați redirecționarea și ruta de întoarcere la sediu.

Firewall-ul hostului este următorul suspect, căci la accesul rutat destinația vede ca sursă o adresă a sediului sau a pool-ului. O regulă scrisă pentru subrețeaua locală nu se potrivește și pachetul este aruncat.

Două proiecte au nevoie de mai mult. Prefixele suprapuse fac destinația ambiguă și necesită renumerotare sau traducere, iar un Access Server în cluster necesită ca fiecare nod să aibă o cale funcțională către conector, nu un singur nod care ține ruta. Aplicați modificările prin calea obișnuită de salvare, reconectați conectorul și verificați din ambele capete; repornirea completă a fiecărei mașini nu face parte din procedură.

Tutorialul site-to-site listează aceleași setări în ordinea produsului; merită urmat o dată înainte de a adapta proiectul.