Hvorfor Access Server-klienter er utilgængelige fra LAN’et

Den bærbare computer opretter forbindelse, tunnelen er oppe, og anmodninger til en intern tjeneste hænger ved forbindelsen. På selve tjenesten ankommer anmodningen fra en adresse som 10.90.0.25, svaret forlader mod standardgatewayen, og intet kommer tilbage, fordi den gateway ikke aner, hvor 10.90.0.25 bor. Fra den anden ende ser den samme fejl ud som en intern vært, der ikke kan pinge en tilsluttet klient. Begge er ét manglende objekt: en returrute til VPN-klientpoolen, som kun det private netværk kan tilføje.

Læs kildeadressen, som tjenesten ser

Det ene felt afgør alt andet. Hvis den interne tjeneste ser pooladressen, router Access Server i stedet for at skjule klienttrafik, og hvert svar skal routes tilbage til poolen. Hvis den i stedet ser serverens egen private adresse, maskerer serveren, og returvejen virker allerede, men på bekostning af at enhver identitet per klient går tabt i tjenestens logfiler og adgangsregler.

Sammenlign begge ender, før du ændrer noget. På serveren, list tunelinterfaces og deres adresser; på klienten, bekræft hvilke af disse adresser den faktisk har; på den interne vært, se på en levende forbindelse.

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

Den sidste kommando er den, der fejler i det brudte tilfælde: den rapporterer enten tunelpræfikset som utilgængeligt eller, værre, returnerer din standardgateway, og det er sådan svar ender på internettet.

Antag ikke, at der kun er én pool. En server kan have et dynamisk interval plus statiske tilknytninger per bruger, og den statiske adresse kan ligge helt uden for det dynamiske præfiks. Hvis du kun router det interval, du husker, forbliver brugere med faste adresser brudte, og alle andre rapporterer problemet som løst.

Tilføj ruten, hvor svaret afgøres

Ruten hører til den gateway, som den interne tjeneste allerede bruger, ikke på tjenesten, medmindre den router sin egen trafik. Peg den på Access Serverens tilgængelige private adresse, som er en anden værdi end den tuneladresse, en klient har.

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

I et cloudnetværk bliver den samme sætning en rutetabelpost, hvis mål er den instans eller det netværksinterface, der kører serveren, med kilde- og destinationskontrol deaktiveret på det interface. Bemærk, hvad den post ikke gør: en rute er ikke en adgangstilladelse, så sikkerhedsgrupper, netværks-ACL’er og værtens firewall skal stadig tillade trafikken.

Gør den vedvarende, og hold poolstørrelserne ærlige. To ikke-sammenhængende pools kræver to ruter, og en pool, der vokser ud over sit konfigurerede præfiks, skaber lydløst klienter, hvis svar ikke har noget sted at gå hen. Hvis du styrer poolintervallerne, vælg et resumé, du kan route én gang og lade være.

Videresendelse og filtre skal passe med ruten

Routing er kun halvdelen af vejen. Serveren skal have lov til at videresende mellem tunnelen og det private interface, hvilket på Linux betyder net.ipv4.ip_forward plus en videresendelseskæde, der tillader de to interfaces, og på en hærdet vært normalt en eksplicit regel for hver retning.

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

Stateful filtrering forklarer et symptom, der sender folk ned ad den forkerte vej. Et svar inde i en etableret strøm har ikke brug for en ny indgående regel, så en forbindelse, der hænger efter SYN-ACK, bliver ikke blokeret af en manglende accept-regel; den bliver droppet eller fejlrouteret. Behold den skelnen, fordi den skiller en ruteændring fra en firewallændring.

Asymmetriske returveje er den mere stille version af det samme problem. Hvis to ruter når poolen, og svaret tager den, der forlader et andet interface end det, anmodningen ankom på, dropper strikt reverse-path-filtrering det, og strømmen fejler kun for nogle klienter.

Rutet eller maskeret: vælg bevidst

Rutet tilstand bevarer klientens pooladresse hos tjenesten, hvilket gør logning og politik per klient mulig, og til gengæld har hvert internt netværk, der skal svare en klient, brug for poolruten. Maskeret tilstand fjerner det krav, fordi svar vender tilbage til serveren, men tjenesten kan ikke længere skelne én klient fra en anden og kan ikke starte noget mod en bestemt klient.

Ændring af den adfærd på en levende server dropper eksisterende sessioner, så test først med én klient og én strøm. Hvis skiftet er det rigtige svar, er det en konfigurationsbeslutning på serveren, ikke noget man omgår ved at tilføje ruter, der bliver unødvendige.

Et subnet bag klienten er en separat opgave

At nå en enhed på den bærbare computers eget LAN er ikke det samme som at nå den bærbare computers tuneladresse. Det kræver, at klienten fungerer som en subnet-gateway: et erklæret netværk på klientsiden, videresendelse aktiveret i klientens styresystem og en rute på det LAN tilbage mod klienten. At tilføje en privatnetværksrute til den bærbare computers hjemmeinterval gør ikke dette, og det skaber konflikter, når to brugere har samme hjemmeinterval.

Retning er også et politisk spørgsmål. Tilladelse til at en klient åbner en forbindelse til en intern tjeneste giver ikke automatisk en intern vært lov til at åbne en forbindelse til den klient. Kontroller serverens adgangspolitik og klientens vært-firewall, før du konkluderer, at vejen er brudt.

Verificér med én strøm og én optagelse

Bevis vejen med en enkelt forbindelse i stedet for en generel tilgængelighedstest. Overvåg den samme strøm i begge ender: anmodningen, der ankommer til tjenesten, og svaret, der forlader den.

tcpdump -ni any host 10.90.0.25 and port 443

Før rettelsen viser optagelsen svaret forlade mod en gateway, der ikke vil route det. Efter rettelsen forlader svaret mod serveren, og strømmen fuldføres. Bekræft derefter den rute, gatewayen ville bruge til en anden klientadresse, så en pool, du ikke har dækket, dukker op nu i stedet for om en uge.

Afslut med de fire kontroller, der lukker sagen: kildeadressen hos tjenesten matcher den tilstand, du havde til hensigt, gatewayen har en rute til hver pool i brug, videresendelse og filtre tillader begge retninger, og én rigtig strøm fuldføres ende til ende. Ofte stillede spørgsmål om Access Server-routing angiver det samme princip for den installerede udgivelse, hvis understøttede konfigurationsgrænseflade kan afvige fra ældre vejledninger.