De ce clienții Access Server nu sunt accesibili din LAN

Laptopul se conectează, tunelul este activ, iar cererile către un serviciu intern se blochează la conectare. La serviciul propriu-zis cererea sosește de la o adresă precum 10.90.0.25, răspunsul pleacă spre gateway-ul implicit și nimic nu se întoarce, pentru că acel gateway nu are nicio idee unde se află 10.90.0.25. Din cealaltă parte, aceeași defecțiune arată ca un host intern care nu poate face ping unui client conectat. Ambele sunt un singur obiect lipsă: o rută de întoarcere către pool-ul de clienți VPN, pe care doar rețeaua privată o poate adăuga.

Citiți adresa sursă pe care o vede serviciul

Acest singur câmp decide tot restul. Dacă serviciul intern vede adresa pool-ului, Access Server rutează în loc să ascundă traficul clienților, iar fiecare răspuns trebuie rutat înapoi în pool. Dacă în schimb vede adresa privată a serverului însuși, serverul face masquerade și calea de întoarcere funcționează deja, cu prețul pierderii oricărei identități per client în jurnalele și regulile de acces ale serviciului.

Comparați ambele capete înainte de a schimba ceva. Pe server, listați interfețele tunelului și adresele lor; pe client, confirmați care dintre aceste adrese o deține de fapt; pe hostul intern, priviți o conexiune activă.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

Ultima comandă este cea care eșuează în cazul defect: fie raportează prefixul tunelului ca inaccesibil, fie, mai rău, returnează gateway-ul implicit, și astfel răspunsurile ajung pe internet.

Nu presupuneți un singur pool. Un server poate avea un interval dinamic plus mapări statice per utilizator, iar adresa statică poate sta complet în afara prefixului dinamic. Dacă rutați doar intervalul de care vă amintiți, utilizatorii cu adrese fixe rămân stricați și toți ceilalți raportează problema ca rezolvată.

Adăugați ruta acolo unde se decide răspunsul

Ruta aparține gateway-ului pe care serviciul intern îl folosește deja, nu serviciului, dacă acesta nu își rutează propriul trafic. Îndreptați-o spre adresa privată accesibilă a Access Server, care este o valoare diferită de adresa tunelului pe care o are un client.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

Într-o rețea de cloud aceeași afirmație devine o intrare în tabela de rutare al cărei țel este instanța sau interfața de rețea pe care rulează serverul, cu verificarea sursei și a destinației dezactivată pe acea interfață. Observați ce nu face acea intrare: o rută nu este o acordare de acces, așa că grupurile de securitate, ACL-urile de rețea și firewall-ul hostului trebuie totuși să permită traficul.

Faceți-o persistentă și păstrați dimensiunile pool-urilor oneste. Două pool-uri necontigue necesită două rute, iar un pool care crește peste prefixul configurat produce în tăcere clienți ale căror răspunsuri nu au unde merge. Dacă controlați intervalele pool-urilor, alegeți o sumarizare pe care o puteți ruta o dată și apoi lăsați-o în pace.

Transmiterea și filtrele trebuie să se potrivească cu ruta

Rutarea este doar jumătate din drum. Serverului trebuie să i se permită să transmită între tunel și interfața privată, ceea ce în Linux înseamnă net.ipv4.ip_forward plus un lanț de transmitere care permite perechea de interfețe, iar pe un host întărit de obicei o regulă explicită pentru fiecare direcție.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Filtrarea cu stare explică un simptom care îi duce pe oameni pe calea greșită. Un răspuns într-un flux stabilit nu are nevoie de o regulă nouă de intrare, așa că o conexiune care se blochează după SYN-ACK nu este blocată de o regulă de acceptare lipsă; este aruncată sau rutată greșit. Păstrați această distincție, pentru că separă o schimbare de rutare de o schimbare de firewall.

Căile de întoarcere asimetrice sunt versiunea mai tăcută a aceleiași probleme. Dacă două rute ajung la pool și răspunsul o ia pe cea care iese printr-o interfață diferită de cea pe care a intrat cererea, filtrarea strictă a căii inverse îl aruncă și fluxul eșuează doar pentru unii clienți.

Rutat sau mascat: alegeți deliberat

Modul rutat păstrează adresa pool-ului clientului la serviciu, ceea ce face posibile jurnalizarea și politica per client, iar în schimb fiecare rețea internă care trebuie să răspundă unui client are nevoie de ruta pool-ului. Modul mascat elimină această cerință pentru că răspunsurile se întorc la server, dar serviciul nu mai poate distinge un client de altul și nu poate iniția nimic către un anumit client.

Schimbarea acestui comportament pe un server activ întrerupe sesiunile existente, așa că testați mai întâi cu un client și un flux. Dacă schimbarea este răspunsul corect, este o decizie de configurare pe server, nu ceva ce se ocolește adăugând rute care vor deveni inutile.

O subrețea în spatele clientului este o sarcină separată

A ajunge la un dispozitiv din chiar LAN-ul laptopului nu este același lucru cu a ajunge la adresa de tunel a laptopului. Necesită ca clientul să acționeze ca gateway de subrețea: o rețea declarată de partea clientului, transmiterea activată în sistemul de operare al clientului și o rută în acel LAN înapoi spre client. Adăugarea unei rute de rețea privată pentru intervalul de acasă al laptopului nu face acest lucru și creează conflicte când doi utilizatori au același interval de acasă.

Direcția este și ea o chestiune de politică. Permisiunea ca un client să deschidă o conexiune către un serviciu intern nu permite automat unui host intern să deschidă o conexiune către acel client. Verificați politica de acces a serverului și firewall-ul hostului clientului înainte de a concluziona că drumul este stricat.

Verificați cu un flux și o captură

Dovediți drumul cu o singură conexiune în loc de un test general de accesibilitate. Urmăriți același flux la ambele capete: cererea care sosește la serviciu și răspunsul care îl părăsește.

tcpdump -ni any host 10.90.0.25 and port 443

Înainte de corectare captura arată răspunsul plecând spre un gateway care nu îl va ruta. După corectare răspunsul pleacă spre server și fluxul se completează. Apoi confirmați ruta pe care gateway-ul ar folosi-o pentru o a doua adresă de client, ca un pool neacoperit să apară acum și nu peste o săptămână.

Încheiați cu cele patru verificări care închid subiectul: adresa sursă la serviciu corespunde modului intenționat, gateway-ul are rută către fiecare pool în uz, transmiterea și filtrele permit ambele direcții, iar un flux real se completează de la un capăt la altul. Întrebări frecvente despre rutarea în Access Server enunță același principiu pentru versiunea instalată, a cărei interfață de configurare acceptată poate diferi de ghidurile vechi.