Waarom Access Server-clients niet bereikbaar zijn vanaf het LAN

De laptop maakt verbinding, de tunnel staat, en verzoeken naar een interne dienst blijven hangen bij het verbinden. Op de dienst zelf komt het verzoek binnen van een adres als 10.90.0.25, het antwoord vertrekt naar de standaardgateway en er komt niets terug, omdat die gateway geen idee heeft waar 10.90.0.25 zich bevindt. Vanaf de andere kant ziet dezelfde fout eruit als een interne host die een verbonden client niet kan pingen. Beide zijn één ontbrekend object: een retourroute naar de VPN-clientpool, die alleen het particuliere netwerk kan toevoegen.

Lees het bronadres dat de dienst ziet

Dat ene veld bepaalt al het andere. Ziet de interne dienst het pooladres, dan routeert de Access Server in plaats van clientverkeer te verbergen, en elk antwoord moet terug naar de pool worden gerouteerd. Ziet hij in plaats daarvan het eigen privéadres van de server, dan maskeert de server en werkt het retourpad al, ten koste van elke identiteit per client in de logs en toegangsregels van de dienst.

Vergelijk beide kanten voordat u iets wijzigt. Op de server, vermeld de tunnelinterfaces en hun adressen; op de client, bevestig welk van die adressen hij werkelijk heeft; op de interne host, bekijk een actieve verbinding.

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

Het laatste commando is degene die in het kapotte geval faalt: het meldt óf het tunnelprefix als onbereikbaar óf, erger, geeft uw standaardgateway terug, en zo belanden antwoorden op internet.

Ga niet uit van één pool. Een server kan een dynamisch bereik plus statische toewijzingen per gebruiker hebben, en het statische adres kan volledig buiten het dynamische prefix liggen. Als u alleen het bereik routeert dat u onthoudt, blijven gebruikers met vaste adressen kapot en meldt iedereen het probleem als opgelost.

Voeg de route toe waar het antwoord wordt bepaald

De route hoort op de gateway die de interne dienst al gebruikt, niet op de dienst, tenzij die zijn eigen verkeer routeert. Richt hem op het bereikbare privéadres van de Access Server, dat een andere waarde is dan het tunneladres dat een client heeft.

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

In een cloudnetwerk wordt dezelfde uitspraak een route-tabelvermelding waarvan het doel de instantie of netwerkinterface is waarop de server draait, met bron- en bestemmingscontrole uitgeschakeld op die interface. Let op wat die vermelding niet doet: een route is geen toegangsverlening, dus beveiligingsgroepen, netwerk-ACL's en de hostfirewall moeten het verkeer nog steeds toestaan.

Maak hem persistent en houd de poolgroottes eerlijk. Twee niet-aaneengesloten pools hebben twee routes nodig, en een pool die voorbij zijn geconfigureerde prefix groeit, levert stilzwijgend clients op waarvan de antwoorden nergens heen kunnen. Als u de poolbereiken beheert, kies een samenvatting die u één keer kunt routeren en dan kunt laten staan.

Doorgifte en filters moeten met de route overeenkomen

Routeren is maar de helft van de weg. De server moet mogen doorsturen tussen de tunnel en de privé-interface, wat op Linux net.ipv4.ip_forward betekent plus een doorstuurketen die het interfacepaar toestaat, en op een geharde host meestal een expliciete regel per richting.

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

Stateful filtering verklaart een symptoom dat mensen het verkeerde pad op stuurt. Een antwoord binnen een bestaande flow heeft geen nieuwe inkomende regel nodig, dus een verbinding die na de SYN-ACK blijft hangen wordt niet geblokkeerd door een ontbrekende accept-regel; hij wordt gedropt of verkeerd gerouteerd. Houd dat onderscheid vast, want het scheidt een routewijziging van een firewallwijziging.

Asymmetrische retourpaden zijn de stillere versie van hetzelfde probleem. Als twee routes de pool bereiken en het antwoord degene neemt die via een andere interface vertrekt dan die waarop het verzoek binnenkwam, gooit strikte reverse-path-filtering hem weg en faalt de flow alleen voor sommige clients.

Gerouteerd of gemaskeerd: kies bewust

Gerouteerde modus bewaart het pooladres van de client bij de dienst, wat logging en beleid per client mogelijk maakt, en in ruil daarvoor heeft elk intern netwerk dat een client moet antwoorden de poolroute nodig. Gemaskeerde modus verwijdert die eis omdat antwoorden teruggaan naar de server, maar de dienst kan niet langer de ene client van de andere onderscheiden en kan niets naar een specifieke client initiëren.

Dat gedrag wijzigen op een live server breekt bestaande sessies af, dus test eerst met één client en één flow. Als de omschakeling het juiste antwoord is, is het een configuratiebeslissing op de server, niet iets dat u omzeilt door routes toe te voegen die daarna overbodig worden.

Een subnet achter de client is een aparte taak

Een apparaat bereiken op het eigen LAN van de laptop is niet hetzelfde als het tunneladres van de laptop bereiken. Het vereist dat de client als subnetgateway fungeert: een gedeclareerd netwerk aan clientzijde, doorgifte ingeschakeld in het besturingssysteem van de client, en een route op dat LAN terug naar de client. Een privénetwerk-route toevoegen voor het thuisbereik van de laptop doet dat niet, en het veroorzaakt conflicten wanneer twee gebruikers hetzelfde thuisbereik hebben.

De richting is ook een beleidsvraag. Toestemming voor een client om een verbinding naar een interne dienst te openen, staat een interne host niet automatisch toe een verbinding naar die client te openen. Controleer het toegangsbeleid van de server en de hostfirewall van de client voordat u concludeert dat het pad kapot is.

Verifieer met één flow en één capture

Bewijs het pad met één verbinding in plaats van een algemene bereikbaarheidstest. Volg dezelfde flow aan beide uiteinden: het verzoek dat bij de dienst aankomt en het antwoord dat hem verlaat.

tcpdump -ni any host 10.90.0.25 and port 443

Vóór de correctie toont de capture het antwoord vertrekken naar een gateway die het niet zal routeren. Na de correctie vertrekt het antwoord naar de server en wordt de flow voltooid. Bevestig daarna de route die de gateway voor een tweede clientadres zou gebruiken, zodat een pool die u niet heeft gedekt nu opvalt en niet over een week.

Sluit af met de vier controles die dit afronden: het bronadres bij de dienst komt overeen met de bedoelde modus, de gateway heeft een route naar elke pool in gebruik, doorgifte en filters staan beide richtingen toe, en één echte flow komt van begin tot eind door. Veelgestelde vragen over routeren met Access Server verwoordt hetzelfde principe voor de geïnstalleerde release, waarvan de ondersteunde configuratie-interface kan afwijken van oudere handleidingen.