CIDR de grup în Access Server: adrese ale membrilor sau rețea de resurse

Într-un grup Access Server două câmpuri acceptă un CIDR și la prima vedere par același tip de intrare: unul descrie adresele oferite membrilor VPN, celălalt descrie rețelele pe care acei membri le pot atinge. Completarea câmpului greșit este acceptată fără eroare, și exact asta face greșeala costisitoare. Primul schimbă planul de adresare al tunelului, al doilea decide ce destinații sunt permise, și niciunul nu îl implică pe celălalt. Există și un al treilea obiect pe care oamenii îl amestecă cu acestea două, subrețeaua din spatele gateway-ului unei sucursale, și ea nu aparține niciunui câmp.

Aceeași sintaxă, întrebări diferite

Întreabă ce numește valoarea. Un CIDR de adrese ale membrilor răspunde la întrebarea ce adrese interne primesc clienții care se conectează, iar mecanismul de alocare îl consumă înainte să curgă vreun trafic. Un CIDR de resursă răspunde la ce destinații poate folosi acest grup, iar regulile de acces îl consumă când un pachet este evaluat. Unul este definiția unui pool, celălalt este o permisiune.

Consecințele confuziei sunt opuse. Un LAN destinație lipit în câmpul pool-ului poate distribui adrese care există deja în acel LAN și poate produce comportament de adrese duplicate, sau poate deplasa pool-ul astfel încât rupe în liniște toate regulile de firewall scrise pentru intervalul vechi. Un pool lipit într-o regulă de acces nu acordă nimic util, pentru că acolo nu locuiește nicio destinație. Ambele greșeli arată la fel: tunelul este sus, dar ceva nu este în regulă.

Alocare: spațiul de adrese al membrilor

Pool-ul nu trebuie să se suprapună cu niciun LAN pe care un membru îl poate atinge și nici cu alt pool VPN din implementare. Este o constrângere de proiectare, nu o setare a produsului: când două locații folosesc ambele 10.90.40.0/24 pentru membri, un membru dintr-o locație nu poate ruta către cealaltă fără traducere, și nicio regulă de acces nu repară asta.

Modul de alocare contează și el. Un pool dinamic dă fiecărui membru următoarea adresă liberă, în timp ce o alocare statică pe utilizator o fixează. Alocarea statică este ceea ce vrei când regulile de firewall sau monitorizarea se referă la membri individuali, și face vizibilă și o schimbare a planului de adresare: adresa fixată se află încă în noul pool sau nu. Citește adresa de tunel a unui membru conectat înainte și după orice modificare a acestui câmp.

Permisiune: rețelele destinație stau în regulile de acces

Accesibilitatea este exprimată în regulile de acces, care numesc grupul sau utilizatorii, o rețea sau un serviciu destinație și metoda de acces. Ultima parte este locul unde mor majoritatea configurărilor pe jumătate terminate: o regulă poate ruta traficul către destinație sau îi poate aplica NAT, iar cele două cer lucruri diferite de la rețea. O cale rutată cere ca partea destinație să știe cum să întoarcă traficul în pool-ul VPN, în timp ce o cale NAT ascunde membrii în spatele unei adrese în care destinația are deja încredere. Documentația grupurilor Access Server ține rețeaua grupului separată de regulile de acces ale grupului, iar etichetele s-au mutat între versiuni.

O destinație permisă are totuși nevoie de o cale utilizabilă. Regula permite, ruta livrează, calea de întoarcere răspunde și serviciul de pe gazdă acceptă. Patru lucruri, patru locuri de privit, și doar primul trăiește în regula de acces. O permisiune verde cu un traceroute mort înseamnă de obicei că lipsește ruta de întoarcere pe gateway-ul destinației, nu că regula este greșită.

Al treilea obiect: o subrețea de sucursală în spatele unui gateway

A declara că un anumit client deține o subrețea este o afirmație de rutare despre o locație, nu o alocare de adrese și nu o permisiune. În termeni Access Server, aceasta este configurația de gateway acceptată pentru o rețea care se conectează, și există pentru că un router de sucursală poate anunța LAN-ul din spatele lui. Membrii primesc în continuare adrese din pool, și au în continuare nevoie de o regulă de acces pentru a folosi acel LAN de sucursală.

Ținerea celor trei separate se plătește la revizuire. O subrețea de sucursală înregistrată ca spațiu de adrese al membrilor grupului arată corect într-o captură de ecran și strică alocarea pentru toți din grup. Aceeași subrețea notată doar într-o regulă de acces acordă acces fără afirmația de proprietate, așa că traficul de întoarcere nu are unde merge. Pune fiecare obiect în coloana lui din proiect și greșeala nu mai este posibilă.

Cum îți dai seama pe care te uiți

Citește eticheta împreună cu vecinii ei. Un câmp lângă un mod de alocare, o dimensiune de pool sau o excepție pe utilizator privește alocarea. Un câmp lângă un selector de grup, un serviciu sau port și o metodă de rutare privește permisiunea. Versiunile redenumesc lucruri, dar vecinii rămân cam la locul lor, de aceea textul dintr-o captură veche este un ghid de navigare slab.

Apoi verifică cu un singur membru în loc de tot grupul: grupul efectiv, adresa de tunel alocată și regula care autorizează destinația dorită. Confirmă ruta, NAT-ul sau calea rutată, traficul de întoarcere și permisiunea serviciului în această ordine, și schimbă doar câmpul care corespunde discrepanței demonstrate. Ține și după aceea evidențele de alocare și permisiune separate, ca o schimbare ulterioară a pool-ului să nu fie citită ca o schimbare în ce poate atinge grupul.