Waarom Access Server-kliënte vanaf die LAN onbereikbaar is

Die skootrekenaar koppel, die tonnel is op, en versoeke na 'n interne diens hang by die koppeling. Op die diens self kom die versoek van 'n adres soos 10.90.0.25, die antwoord vertrek na die verstek-roeteerder, en niks kom terug nie, want daardie roeteerder het geen idee waar 10.90.0.25 woon nie. Vanaf die ander kant lyk dieselfde fout soos 'n interne gasheer wat nie 'n gekoppelde kliënt kan ping nie. Albei is een ontbrekende objek: 'n terugroete na die VPN-kliëntpoel, wat net die private netwerk kan byvoeg.

Lees die bronadres wat die diens sien

Daardie enkele veld bepaal alles anders. As die interne diens die poeladres sien, roeteer die Access Server eerder as om kliëntverkeer weg te steek, en elke antwoord moet terug na die poel geroteer word. As dit eerder die bediener se eie private adres sien, doen die bediener aan vermomming en die antwoordpad werk al, ten koste daarvan dat enige per-kliënt-identiteit in die diens se logboeke en toegangsreëls verlore gaan.

Vergelyk albei kante voordat jy iets verander. Op die bediener, lys die tonnelkoppelvlakke en hul adresse; op die kliënt, bevestig watter van daardie adresse dit werklik het; op die interne gasheer, kyk na 'n lewendige verbinding.

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

Die laaste opdrag is die een wat in die gebreekte geval misluk: dit rapporteer óf die tonnelvoorvoegsel as onbereikbaar óf, erger, gee jou verstek-roeteerder terug, en dit is hoe antwoorde op die internet beland.

Moenie aanvaar dat daar net een poel is nie. 'n Bediener kan 'n dinamiese reeks plus per-gebruiker statiese toewysings hê, en die statiese adres kan heeltemal buite die dinamiese voorvoegsel lê. As jy net die reeks roeteer wat jy onthou, bly die gebruikers met vaste adresse stukkend en almal anders rapporteer die probleem as opgelos.

Voeg die roete by waar die antwoord besluit word

Die roete hoort op die roeteerder wat die interne diens al gebruik, nie op die diens nie, tensy dit sy eie verkeer roeteer. Wys dit na die Access Server se bereikbare private adres, wat 'n ander waarde is as die tonneladres wat 'n kliënt het.

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

In 'n wolknetwerk word dieselfde stelling 'n roetetabel-inskrywing wie se teiken die instansie of netwerkkoppelvlak is wat die bediener laat loop, met bron- en bestemmingkontrole gedeaktiveer op daardie koppelvlak. Let op wat daardie inskrywing nie doen nie: 'n roete is nie 'n toegangsverlening nie, so sekuriteitsgroepe, netwerk-ACL's en die gasheer se vuurmuur moet steeds die verkeer toelaat.

Maak dit blywend, en hou die poelgroottes eerlik. Twee nie-aangrensende poele het twee roetes nodig, en 'n poel wat verby sy gekonfigureerde voorvoegsel groei, produseer stilweg kliënte wie se antwoorde nêrens heen het nie. As jy die poelreekse beheer, kies 'n samevatting wat jy een keer kan roeteer en alleen kan laat.

Stuur en filters moet met die roete saamstem

Roetering is net die helfte van die pad. Die bediener moet toegelaat word om tussen die tonnel en die private koppelvlak te stuur, wat op Linux net.ipv4.ip_forward beteken plus 'n stuurketting wat die paar koppelvlakke toelaat, en op 'n verharde gasheer gewoonlik 'n eksplisiete reël vir elke rigting.

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

Stateful filtering verduidelik 'n simptoom wat mense op die verkeerde pad stuur. 'n Antwoord binne 'n gevestigde vloei het nie 'n nuwe inkomende reël nodig nie, so 'n verbinding wat ná die SYN-ACK hang, word nie deur 'n ontbrekende toelaatreël geblokkeer nie; dit word laat val of verkeerd geroteer. Hou daardie onderskeid, want dit skei 'n roeteverandering van 'n vuurmuurverandering.

Asimmetriese terugpaaie is die stiller weergawe van dieselfde probleem. As twee roetes die poel bereik en die antwoord neem die een wat van 'n ander koppelvlak vertrek as waarop die versoek aangekom het, laat streng terugpadfiltering dit val en die vloei misluk net vir sommige kliënte.

Geroteer of vermom: kies doelbewus

Geroteerde modus bewaar die kliënt se poeladres by die diens, wat per-kliënt-logging en per-kliënt-beleid moontlik maak, en in ruil daarvoor het elke interne netwerk wat 'n kliënt moet antwoord die poelroete nodig. Vermomde modus verwyder daardie vereiste omdat antwoorde na die bediener terugkeer, maar die diens kan nie meer een kliënt van 'n ander onderskei nie en kan niks na 'n spesifieke kliënt inisieer nie.

Om daardie gedrag op 'n lewendige bediener te verander, laat bestaande sessies val, so toets eers met een kliënt en een vloei. As die skakel die regte antwoord is, is dit 'n konfigurasiebesluit op die bediener, nie iets om te omseil deur roetes by te voeg wat onnodig sal word nie.

'n Subnet agter die kliënt is 'n aparte taak

Om 'n toestel op die skootrekenaar se eie LAN te bereik is nie dieselfde as om die skootrekenaar se tonneladres te bereik nie. Dit vereis dat die kliënt as 'n subnet-roeteerder optree: 'n verklaarde kliëntkant-netwerk, stuur geaktiveer op die kliënt se bedryfstelsel, en 'n roete op daardie LAN terug na die kliënt. Om 'n private-netwerkroete vir die skootrekenaar se tuisreeks by te voeg, doen dit nie, en dit skep konflikte wanneer twee gebruikers dieselfde tuisreeks het.

Rigting is ook 'n beleidsvraag. Toestemming vir 'n kliënt om 'n verbinding na 'n interne diens oop te maak, laat nie outomaties 'n interne gasheer toe om 'n verbinding na daardie kliënt oop te maak nie. Kontroleer die bediener se toegangsbeleid en die kliënt se gasheer-vuurmuur voordat jy aflei dat die pad stukkend is.

Verifieer met een vloei en een opname

Bewys die pad met 'n enkele verbinding eerder as 'n algemene bereikbaarheidstoets. Kyk na dieselfde vloei aan albei kante: die versoek wat by die diens aankom en die antwoord wat dit verlaat.

tcpdump -ni any host 10.90.0.25 and port 443

Voor die regstelling wys die opname die antwoord wat na 'n roeteerder vertrek wat dit nie sal roeteer nie. Ná die regstelling vertrek die antwoord na die bediener en die vloei voltooi. Bevestig dan die roete wat die roeteerder vir 'n tweede kliëntadres sou gebruik, sodat 'n poel wat jy nie gedek het nie, nou opduik eerder as oor 'n week.

Sluit af met die vier kontroles wat dit afhandel: die bronadres by die diens stem ooreen met die modus wat jy bedoel het, die roeteerder het 'n roete na elke poel in gebruik, stuur en filters laat albei rigtings toe, en een werklike vloei voltooi van begin tot end. Die Access Server-roetevrae stel dieselfde beginsel vir die geïnstalleerde weergawe, wie se ondersteunde konfigurasiekoppelvlak van ouer gidse kan verskil.