Kvifor Access Server-klientar ikkje er tilgjengelege frå LAN-et

Den berebære maskina koplar til, tunnelen er oppe, og førespurnader til ei intern teneste heng ved tilkopling. På sjølve tenesta kjem førespurnaden frå ei adresse som 10.90.0.25, svaret går mot standardgatewayen, og ingenting kjem tilbake, fordi den gatewayen ikkje veit kvar 10.90.0.25 bur. Frå den andre enden ser same feilen ut som ein intern vert som ikkje kan pinge ein tilkopla klient. Begge er eitt manglande objekt: ei returrute til VPN-klientpoolen, som berre det private nettet kan leggje til.

Les kjeldeadressa tenesta ser

Det eine feltet avgjer alt anna. Viss den interne tenesta ser pooladressa, rutar Access Server i staden for å skjule klienttrafikk, og kvart svar må rutast tilbake til poolen. Viss ho i staden ser den private adressa til serveren sjølv, maskerer serveren, og returvegen verkar allereie, men på kostnad av at kvar identitet per klient går tapt i loggane og tilgangsreglane til tenesta.

Samanlikne begge endar før du endrar noko. På serveren, list tunnelgrensesnitta og adressene deira; på klienten, stadfest kva av desse adressene han faktisk har; på den interne verten, sjå på ei levande tilkopling.

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

Den siste kommandoen er den som feilar i det øydelagde tilfellet: han rapporterer anten tunnelprefikset som utilgjengeleg eller, verre, returnerer standardgatewayen din, og det er slik svar hamnar på internett.

Ikkje gå ut frå at det berre er éin pool. Ein server kan ha eit dynamisk område pluss statiske tildelingar per brukar, og den statiske adressa kan liggje heilt utanfor det dynamiske prefikset. Viss du berre rutar området du hugsar, blir brukarar med faste adresser verande øydelagde, og alle andre rapporterer problemet som løyst.

Legg til ruta der svaret blir avgjort

Ruta høyrer til gatewayen som den interne tenesta allereie brukar, ikkje på tenesta, med mindre ho rutar sin eigen trafikk. Peik henne mot den tilgjengelege private adressa til Access Server, som er ein annan verdi enn tunneladressa ein klient har.

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

I eit skynettverk blir den same setninga ein rutingtabellpost der målet er instansen eller nettverksgrensesnittet som køyrer serveren, med kjelde- og målkontroll deaktivert på det grensesnittet. Legg merke til kva den posten ikkje gjer: ei rute er ikkje ei tilgangsløyve, så tryggingsgrupper, nettverks-ACL-ar og brannmuren til verten må framleis tillate trafikken.

Gjer henne varig, og hald poolstorleikane ærlege. To ikkje-samanhengande poolar treng to ruter, og ein pool som veks utover det konfigurerte prefikset sitt produserer stille klientar som svara deira ikkje har nokon stad å gå. Viss du kontrollerer poolområda, vel eit samandrag du kan rute éin gong og la vere.

Videresending og filter må stemme med ruta

Ruting er berre halve vegen. Serveren må få løyve til å videresende mellom tunnelen og det private grensesnittet, noko som på Linux tyder net.ipv4.ip_forward pluss ei videresendingskjede som tillèt grensesnittparet, og på ein herda vert vanlegvis ein eksplisitt regel for kvar retning.

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

Stateful filtrering forklarer eit symptom som sender folk ned feil veg. Eit svar inne i ein etablert straum treng ikkje ein ny inngåande regel, så ei tilkopling som heng etter SYN-ACK blir ikkje blokkert av ein manglande accept-regel; ho blir droppa eller feilruta. Hald på den skilnaden, fordi han skil ei ruteendring frå ei brannmurrendring.

Asymmetriske returvegar er den stillare versjonen av det same problemet. Viss to ruter når poolen, og svaret tek den som går ut gjennom eit anna grensesnitt enn det førespurnaden kom inn på, droppar streng reverse-path-filtrering det, og straumen feilar berre for nokre klientar.

Ruta eller maskert: vel medvite

Ruta modus bevarer pooladressa til klienten hos tenesta, noko som gjer logging og policy per klient mogleg, og til gjengjeld treng kvart interne nettverk som skal svare ein klient poolruta. Maskert modus fjernar det kravet fordi svara går tilbake til serveren, men tenesta kan ikkje lenger skilje éin klient frå ein annan og kan ikkje starte noko mot ein bestemt klient.

Å endre den åtferda på ein levande server droppar eksisterande økter, så test først med éin klient og éin straum. Viss byttet er det rette svaret, er det ei konfigurasjonsavgjerd på serveren, ikkje noko ein omgår ved å leggje til ruter som blir unødvendige.

Eit subnett bak klienten er ei eiga oppgåve

Nå ein eining på det eigne LAN-et til den berebære maskina er ikkje det same som å nå tunneladressa til den berebære maskina. Det krev at klienten fungerer som ein subnett-gateway: eit erklært nettverk på klientsida, videresending aktivert i operativsystemet til klienten, og ei rute på det LAN-et tilbake mot klienten. Å leggje til ei privatnett-rute for heimeområdet til den berebære maskina gjer ikkje dette, og det skaper konfliktar når to brukarar har same heimeområde.

Retning er også eit policy-spørsmål. Løyve for ein klient til å opne ei tilkopling til ei intern teneste gir ikkje automatisk ein intern vert lov til å opne ei tilkopling til den klienten. Sjekk tilgangspolicyen til serveren og vertsbrannmuren til klienten før du konkluderer med at vegen er øydelagd.

Stadfest med éin straum og eitt opptak

Prov vegen med éi einskild tilkopling i staden for ein generell tilgjengelegheitstest. Følg med på den same straumen i begge endar: førespurnaden som kjem til tenesta, og svaret som forlèt henne.

tcpdump -ni any host 10.90.0.25 and port 443

Før rettinga viser opptaket svaret gå mot ein gateway som ikkje vil rute det. Etter rettinga går svaret mot serveren, og straumen blir fullført. Stadfest deretter ruta gatewayen ville brukt for ei andre klientadresse, slik at ein pool du ikkje har dekt dukkar opp no og ikkje om ei veke.

Avslutt med dei fire kontrollane som lukkar saka: kjeldeadressa hos tenesta svarar til modusen du hadde tenkt, gatewayen har ei rute til kvar pool i bruk, videresending og filter tillèt begge retningar, og éin ekte straum blir fullført frå ende til annan. Ofte stilte spørsmål om Access Server-ruting seier det same prinsippet for den installerte utgåva, der det støtta konfigurasjonsgrensesnittet kan avvike frå eldre rettleiingar.