Hvorfor Access Server-klienter ikke er tilgjengelige fra LAN-et

Den bærbare maskinen kobler til, tunnelen er oppe, og forespørsler til en intern tjeneste henger ved tilkobling. På selve tjenesten kommer forespørselen fra en adresse som 10.90.0.25, svaret forlater mot standardgatewayen, og ingenting kommer tilbake, fordi den gatewayen ikke aner hvor 10.90.0.25 bor. Fra den andre enden ser den samme feilen ut som en intern vert som ikke kan pinge en tilkoblet klient. Begge er ett manglende objekt: en returrute til VPN-klientpoolen, som bare det private nettet kan legge til.

Les kildeadressen tjenesten ser

Det ene feltet avgjør alt annet. Hvis den interne tjenesten ser pooladressen, ruter Access Server i stedet for å skjule klienttrafikk, og hvert svar må rutes tilbake til poolen. Hvis den i stedet ser serverens egen private adresse, maskerer serveren, og returveien virker allerede, men på bekostning av at enhver identitet per klient går tapt i tjenestens logger og tilgangsregler.

Sammenlign begge ender før du endrer noe. På serveren, list tunnelgrensesnittene og adressene deres; på klienten, bekreft hvilke av disse adressene den faktisk har; på den interne verten, se på en levende tilkobling.

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

Den siste kommandoen er den som feiler i det ødelagte tilfellet: den rapporterer enten tunnelprefikset som utilgjengelig eller, verre, returnerer standardgatewayen din, og det er slik svar havner på internett.

Ikke anta at det bare er én pool. En server kan ha et dynamisk område pluss statiske tilordninger per bruker, og den statiske adressen kan ligge helt utenfor det dynamiske prefikset. Hvis du bare ruter området du husker, forblir brukere med faste adresser ødelagte, og alle andre rapporterer problemet som løst.

Legg til ruten der svaret avgjøres

Ruten hører til gatewayen som den interne tjenesten allerede bruker, ikke på tjenesten, med mindre den ruter sin egen trafikk. Pek den mot Access Servers tilgjengelige private adresse, som er en annen verdi enn tunneladressen 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 skybasert nettverk blir den samme setningen en rutingtabelloppføring der målet er instansen eller nettverksgrensesnittet som kjører serveren, med kilde- og destinasjonskontroll deaktivert på det grensesnittet. Legg merke til hva den oppføringen ikke gjør: en rute er ikke en tilgangstillatelse, så sikkerhetsgrupper, nettverks-ACL-er og vertens brannmur må fortsatt tillate trafikken.

Gjør den varig, og hold poolstørrelsene ærlige. To ikke-sammenhengende pooler trenger to ruter, og en pool som vokser utover sitt konfigurerte prefiks produserer stille klienter hvis svar ikke har noe sted å gå. Hvis du kontrollerer poolområdene, velg et sammendrag du kan rute én gang og la være.

Videresending og filtre må stemme med ruten

Ruting er bare halve veien. Serveren må få lov til å videresende mellom tunnelen og det private grensesnittet, noe som på Linux betyr net.ipv4.ip_forward pluss en videresendingskjede som tillater grensesnittparet, og på en herdet vert vanligvis en eksplisitt regel for hver retning.

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

Stateful filtrering forklarer et symptom som sender folk ned feil vei. Et svar inne i en etablert strøm trenger ikke en ny innkommende regel, så en tilkobling som henger etter SYN-ACK blir ikke blokkert av en manglende accept-regel; den blir droppet eller feilrutet. Behold den forskjellen, fordi den skiller en ruteendring fra en brannmurrendring.

Asymmetriske returveier er den stillere versjonen av det samme problemet. Hvis to ruter når poolen, og svaret tar den som forlater et annet grensesnitt enn det forespørselen kom inn på, dropper streng reverse-path-filtrering det, og strømmen feiler bare for noen klienter.

Rutet eller maskert: velg bevisst

Rutet modus bevarer klientens pooladresse hos tjenesten, noe som gjør logging og policy per klient mulig, og til gjengjeld trenger hvert interne nettverk som skal svare en klient poolruten. Maskert modus fjerner det kravet fordi svarene går tilbake til serveren, men tjenesten kan ikke lenger skille én klient fra en annen og kan ikke starte noe mot en bestemt klient.

Å endre den atferden på en levende server dropper eksisterende økter, så test først med én klient og én strøm. Hvis byttet er det riktige svaret, er det en konfigurasjonsbeslutning på serveren, ikke noe man omgår ved å legge til ruter som blir unødvendige.

Et subnett bak klienten er en egen oppgave

Nå en enhet på den bærbare maskinens eget LAN er ikke det samme som å nå den bærbare maskinens tunneladresse. Det krever at klienten fungerer som en subnett-gateway: et erklært nettverk på klientsiden, videresending aktivert i klientens operativsystem, og en rute på det LAN-et tilbake mot klienten. Å legge til en privatnett-rute for den bærbare maskinens hjemmeområde gjør ikke dette, og det skaper konflikter når to brukere har samme hjemmeområde.

Retning er også et policy-spørsmål. Tillatelse for en klient til å åpne en tilkobling til en intern tjeneste gir ikke automatisk en intern vert lov til å åpne en tilkobling til den klienten. Sjekk serverens tilgangspolicy og klientens vertsbrannmur før du konkluderer med at veien er ødelagt.

Verifiser med én strøm og ett opptak

Bevis veien med én enkelt tilkobling i stedet for en generell tilgjengelighetstest. Følg med på den samme strømmen i begge ender: forespørselen som ankommer tjenesten, og svaret som forlater den.

tcpdump -ni any host 10.90.0.25 and port 443

Før rettelsen viser opptaket svaret forlate mot en gateway som ikke vil rute det. Etter rettelsen forlater svaret mot serveren, og strømmen fullføres. Bekreft deretter ruten gatewayen ville brukt for en andre klientadresse, slik at en pool du ikke har dekket dukker opp nå og ikke om en uke.

Avslutt med de fire kontrollene som lukker saken: kildeadressen hos tjenesten samsvarer med modusen du hadde tenkt, gatewayen har en rute til hver pool i bruk, videresending og filtre tillater begge retninger, og én ekte strøm fullføres ende til ende. Ofte stilte spørsmål om Access Server-ruting angir det samme prinsippet for den installerte utgivelsen, hvis støttede konfigurasjonsgrensesnitt kan avvike fra eldre veiledninger.