LAN achter één AWS Client VPN-sessie: wat er wordt doorgestuurd

De laptop maakt verbinding met het AWS Client VPN-eindpunt, bereikt het privé-subnet en alles ziet er gezond uit. De desktop op hetzelfde LAN bereikt niets, hoewel de Linux-host ook een bridge-interface heeft en beide machines op dezelfde kabel zitten. Niets is verkeerd geconfigureerd in de tunnel; het ontbrekende stuk is routering, en de bridge is een dwaalspoor.

Een Client VPN-sessie uitbreiden naar een LAN is een gatewayrol. Het is geen Ethernet-segment dat in een beheerde dienst wordt uitgerekt.

De host werkt en het LAN niet

De tunnelinterface op de Linux-machine heeft een adres binnen de CIDR van de Client VPN-client, en het eindpunt heeft routes voor de VPC-bereiken gepusht. Een verzoek op die machine is lokaal gegenereerd verkeer: het kiest een route, verlaat de host via de tunnel en krijgt een antwoord. Dat pad raakt nooit de doorvoercode, de LAN-interface of een firewallregel die het transitoverkeer regelt.

Verkeer van een ander LAN-apparaat is een andere stroom. Het komt binnen op de LAN-interface, heeft een route nodig die de tunnel in wijst, heeft doorgifte ingeschakeld nodig, heeft een firewall nodig die het toestaat, en heeft nodig dat het antwoord via dezelfde host terugkomt. Vier vereisten, en de werkende laptoptest bewijst er geen enkele. Vanaf de desktop ziet de fout er vreemd uit: de tunnel staat, de inloggegevens zijn geldig, en de bestemming antwoordt gewoon nooit. Het defect zit lokaal in het doorgeefpad van de gateway, niet in de dienst.

Niet elke client kan een gateway zijn

AWS stelt dat de Client VPN-desktopapp geen IP-doorgifte ondersteunt, en dat andere clients dat wel kunnen. Die beperking bepaalt de architectuur voordat er een commando wordt getypt. Als de enige beschikbare client de officiële desktopapp is, is een Linux-gateway die voor het LAN doorgeeft geen configuratie die je kunt afmaken, en geen enkele hoeveelheid masquerading verandert dat.

De vervangende client moet ook passen bij de authenticatiemethode van het eindpunt en het beleid dat je wilt afdwingen. Eindpunten op basis van certificaten, directory en SAML accepteren niet dezelfde clientconfiguraties, en een client van derden die authenticeert maar de gepushte routes negeert is geen verbetering.

Behandel de clientkeuze als onderdeel van de ontwerpbeoordeling. Die bepaalt of het LAN-doorgiftepatroon überhaupt beschikbaar is, en bepaalt welke identiteit het eindpunt ziet voor elk apparaat achter de gateway. Leg de client en de eindpuntconfiguratie vast waartegen is getest. Een clientwissel zes maanden later kan de capaciteit die het ontwerp aannam stilzwijgend weghalen.

Leid het LAN naar de tunnel en vertaal het

Met een ondersteunde client op zijn plaats is de rest gewoon gatewaywerk. De LAN-apparaten hebben een route voor het VPC-bereik nodig die naar de Linux-host wijst, en de host heeft doorgifte ingeschakeld nodig. Als je wilt dat de VPC het verkeer ziet als de verbonden client en niet als een willekeurig LAN-adres, vertaal dan de bron bij het verlaten.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Beperk de regel tot de tunnelinterface en het VPC-bereik, zoals hierboven, in plaats van alles te masqueraden wat de host doorgeeft. De smallere regel is makkelijker te beredeneren, en hij verandert niet stilzwijgend verkeer dat zijn oorspronkelijke bronadres moest behouden.

Laat de LAN-route automatisch komen als je kunt: een DHCP-optie, een routeraankondiging of een statische route die wordt gepusht door wat het LAN beheert. Een route die alleen op één testmachine bestaat, laat het ontwerp kapot lijken op het moment dat iemand anders het probeert.

Het antwoord heeft ook een pad nodig

Zodra het verzoek de VPC bereikt, moet het antwoord terugkomen via dezelfde vertaaltoestanden en de LAN-route op de gateway vinden. Dat deel werkt meestal wanneer de masquerade-regel aanwezig is, omdat de mapping leeft op de host die hem heeft uitgevoerd. Het breekt wanneer de VPC-kant een route heeft die het antwoord elders heen stuurt, en daarom zijn zowel de client-CIDR-route als de subnetkoppeling op het eindpunt belangrijk.

Kijk naar de tellers, niet alleen naar de ping. Een masquerade-regel met nul pakketten vertelt je dat het verzoek de tunnelinterface nooit heeft bereikt, wat terugwijst naar de LAN-route of de eigen routeringstabel van de client. Een regel met pakketten maar zonder antwoorden wijst op de VPC-kant, de autorisatieregels of een beveiligingsgroep die de vertaalde bron niet accepteert. Lees beide richtingen voordat je iets verandert, want een teller die maar aan één kant groeit is een eenrichtingspad, geen langzaam pad.

Onthoud dat het eindpunt een beheerde dienst is. Er is geen serverconfiguratiebestand om te bewerken en geen client-config-directief om toe te voegen, dus instructies die zijn geschreven voor een zelfbeheerde OpenVPN-server met aangepaste client-subnetroutes gaan niet over. Op AWS zijn de hefbomen subnetkoppeling, autorisatieregels en de routeringstabellen van de VPC.

Gedeelde identiteit is het deel waarop beleid antwoord moet geven

Elk apparaat achter de gateway gebruikt de VPN-sessie van de gateway. De autorisatieregels van het eindpunt verlenen toegang aan een gebruiker of een groep, en vanuit het perspectief van de dienst is er precies één gebruiker op die sessie. Lokale doorgifte vermenigvuldigt die identiteit niet tot authenticatie per apparaat, en breidt apparaatpostuurcontroles niet uit naar de printer in de hoek.

Dat kan acceptabel zijn, of het kan de reden zijn dat het ontwerp wordt afgewezen. Het hangt ervan af wat de VPC-resources aannemen over wie er belt. Een gedeelde identiteit die bij het autorisatiemodel past is prima; een die stilzwijgend één geauthenticeerde sessie omzet in toegang tot het hele LAN is een bevinding die opgeschreven moet worden.

Als de eis echt is om een hele locatie aan een VPC te koppelen, vergelijk dan een ondersteund site-naar-site-ontwerp voordat je een client voor externe toegang uitbreidt. De semantiek verschilt, en een met NAT vertaalde clientsessie is een slechte vervanging voor een locatieverbinding wanneer de VPC verbindingen naar het LAN moet initiëren.

Bepaal de client, de route, de vertaling en het identiteitsverhaal in die volgorde. Elk beperkt het volgende, en de volgorde verklaart waarom de host werkt terwijl het LAN dat niet doet.