LAN bakom en AWS Client VPN-session: vad som vidarebefordras

Den bärbara datorn ansluter till AWS Client VPN-slutpunkten, når det privata subnätet och allt ser friskt ut. Skrivbordet på samma LAN når ingenting, trots att Linux-värden också har ett brygggränssnitt och båda maskinerna sitter på samma kabel. Ingenting är felkonfigurerat i tunneln; den saknade biten är routning, och bryggan är ett villospår.

Att utöka en Client VPN-session till ett LAN är en gatewayroll. Det är inte ett Ethernet-segment som sträcks in i en hanterad tjänst.

Värden fungerar och LAN gör det inte

Tunnelgränssnittet på Linux-maskinen har en adress inom Client VPN-klientens CIDR, och slutpunkten har pushat rutter för VPC-intervallen. En förfrågan som görs på den maskinen är lokalt genererad trafik: den väljer en rutt, lämnar genom tunneln och får ett svar. Den vägen rör aldrig vidarebefordrans koden, LAN-gränssnittet eller någon brandväggsregel som styr transit.

Trafik från en annan LAN-enhet är ett annat flöde. Den anländer på LAN-gränssnittet, behöver en rutt som pekar in i tunneln, behöver vidarebefordran aktiverad, behöver en brandvägg som tillåter den och behöver att svaret kommer tillbaka genom samma värd. Fyra krav, och det fungerande bärbaratestet bevisar inget av dem. Från skrivbordet ser felet bisarrt ut: tunneln är uppe, autentiseringsuppgifterna är giltiga och målet svarar bara aldrig. Defekten är lokal i gatewayens vidarebefordransväg, inte i tjänsten.

Inte alla klienter kan vara en gateway

AWS uppger att deras skrivbordsapp för Client VPN inte stöder IP-vidarebefordran, och att andra klienter kan göra det. Den begränsningen avgör arkitekturen innan något kommando skrivs. Om den enda tillgängliga klienten är den officiella skrivbordsappen är en Linux-gateway som vidarebefordrar för LAN inget du kan slutföra, och ingen mängd masquerading ändrar det.

Ersättningsklienten måste också matcha slutpunktens autentiseringsmetod och den policy du tänker tillämpa. Slutpunkter baserade på certifikat, katalog och SAML accepterar inte samma klientkonfigurationer, och en tredjepartsklient som autentiserar men ignorerar de pushade rutterna är ingen förbättring.

Behandla klientvalet som en del av designgranskningen. Det avgör om LAN-vidarebefordringsmönstret är tillgängligt överhuvudtaget, och det avgör vilken identitet slutpunkten ser för varje enhet bakom gatewayen. Registrera klienten och den slutpunktskonfiguration den testades mot. Ett klientbyte sex månader senare kan tyst ta bort förmågan som designen antog.

Rikta LAN till tunneln och översätt det

Med en stödd klient på plats är resten vanligt gatewayarbete. LAN-enheterna behöver en rutt för VPC-intervallet som pekar på Linux-värden, och värden behöver vidarebefordran aktiverad. Om du vill att VPC ska se trafiken som den anslutna klienten och inte som en godtycklig LAN-adress, översätt källan på väg ut.

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

Begränsa regeln till tunnelgränssnittet och VPC-intervallet, som ovan, i stället för att masquerade allt värden vidarebefordrar. Den snävare regeln är lättare att resonera om, och den ändrar inte tyst trafik som skulle behålla sin ursprungliga källadress.

Låt LAN-rutten komma automatiskt om du kan: ett DHCP-alternativ, en routerannonsering eller en statisk rutt som pushas av det som hanterar LAN. En rutt som bara finns på en testmaskin får designen att se trasig ut i samma ögonblick som någon annan provar den.

Svaret behöver också en väg

När förfrågan når VPC måste svaret komma tillbaka genom samma översättningstillstånd och hitta LAN-rutten på gatewayen. Den delen fungerar oftast när masquerade-regeln är på plats, eftersom mappningen lever på värden som utförde den. Den går sönder när VPC-sidan har en rutt som skickar svaret någon annanstans, och det är därför både klient-CIDR-rutten och subnätstilldelningen på slutpunkten spelar roll.

Titta på räknarna, inte bara på ping. En masquerade-regel med noll paket säger att förfrågan aldrig nådde tunnelgränssnittet, vilket pekar tillbaka på LAN-rutten eller klientens egen routingtabell. En regel med paket men utan svar pekar på VPC-sidan, auktoriseringsreglerna eller en säkerhetsgrupp som inte accepterar den översatta källan. Läs båda riktningarna innan du ändrar något, för ett tal som bara växer på ena sidan är en enkelriktad väg, inte en långsam.

Kom ihåg att slutpunkten är en hanterad tjänst. Det finns ingen serverkonfigurationsfil att redigera och inget client-config-direktiv att lägga till, så instruktioner skrivna för en självhanterad OpenVPN-server med anpassade klient-subnätsrutter överförs inte. På AWS är spakarna subnätstilldelning, auktoriseringsregler och VPC:ns routingtabeller.

Delad identitet är den del som policyn måste svara på

Varje enhet bakom gatewayen använder gatewayens VPN-session. Slutpunktens auktoriseringsregler ger åtkomst till en användare eller en grupp, och ur tjänstens synvinkel finns exakt en användare på den sessionen. Lokal vidarebefordran mångfaldigar inte den identiteten till autentisering per enhet, och den utökar inte enhetsstatuskontroller till skrivaren i hörnet.

Det kan vara acceptabelt, eller så kan det vara anledningen till att designen avvisas. Det beror på vad VPC-resurserna förutsätter om vem som ringer. En delad identitet som passar auktoriseringsmodellen är okej; en som tyst förvandlar en enda autentiserad session till åtkomst för hela LAN är ett fynd som väntar på att skrivas.

Om kravet verkligen är att ansluta en hel plats till ett VPC, jämför en stödd plats-till-plats-design innan du utökar en fjärråtkomstklient. Semantiken skiljer sig, och en NAT:ad klientsession är en dålig ersättning för en platslänk när VPC måste initiera anslutningar in i LAN.

Bestäm klienten, rutten, översättningen och identitetshistorien i den ordningen. Var och en begränsar nästa, och ordningen förklarar varför värden fungerar medan LAN inte gör det.