Full tunnel för Access Server på EC2: varför en kryssruta inte räcker

Att stänga av käll- och målkontrollen på en EC2-instans är det mest upprepade svaret på frågor om Access Servers internetutgång, och i sig gör det ingenting för dina klienter. Kontrollen är en vidarebefordringsbegränsning i AWS: den får instansen att acceptera paket vars källa eller mål inte är dess egen adress. Den säger inte till Access Server-klienten att skicka internettrafik genom tunneln, den skapar ingen väg uppåt och den lägger inte till NAT. Myten är att kryssrutan är funktionen.

Vad kontrollen faktiskt styr

Varje EC2-nätverksgränssnitt kastar trafik som inte är adresserad till det, om inte instansen fungerar som router, NAT-enhet eller VPN-gateway och du stänger av kontrollen. Att stänga av den ger tillstånd att vidarebefordra. Tillstånd är inte konfiguration: instansen behöver fortfarande en väg till en internetgateway eller NAT-enhet, VPC-rutttabellen behöver fortfarande den matchande posten, säkerhetsgrupper måste fortfarande tillåta flödet, och servern måste fortfarande översätta eller routa returtrafiken.

Kontrollera det aktuella värdet med aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck innan du ändrar något. Om du ändrar det i konsolen, gör det för att instansen vidarebefordrar för andra, inte för att en klient inte når internet.

Access Server äger klientens routningspolicy

I Access Server 3 öppnar du Access Controls och hittar avsnittet Internet Access and DNS. Valet Internet Gateway erbjuder full tunnel eller delad tunnel; full tunnel säger till klienten att routa sin standardtrafik in i VPN, delad tunnel låter internettrafiken stanna på klientens lokala väg. Spara och tillämpa via produktens arbetsflöde och återanslut sedan en testklient, eftersom policyn levereras vid anslutningstillfället.

Äldre utgåvor använder andra menyer och vissa Community OpenVPN-byggen har ingen motsvarande kontroll. Kontrollera den installerade huvudversionen innan du letar efter en skärm som inte finns. Bekräfta sedan vad klienten fick: en full tunnel-profil bör installera en standardväg genom tunneln, och en delad tunnel-profil bör inte göra det.

Följ paketet efter tunneln

När klienten skickar internettrafik in i tunneln måste servern vidarebefordra den och vanligtvis översätta den. Access Server hanterar sina egna NAT- och routningsregler, så läs den effektiva konfigurationen i stället för att lägga till Community OpenVPN-regler i genererade filer; ohanterade regler skrivs över eller krockar vid nästa produktuppdatering. sudo iptables -t nat -L -n -v eller nftables-motsvarigheten visar vad som faktiskt översätts.

AWS-sidan är en separat väg. En instans i ett offentligt subnät når en internetgateway direkt och behåller sin offentliga adress eller elastiska IP. En instans i ett privat subnät behöver en väg till en NAT-gateway eller NAT-instans, och NAT-enheten behöver sin egen väg till internetgatewayen. Att koppla en internetgateway till VPC ger inte i sig någon privat källa en offentlig returadress, och därför fungerar samma Access Server-konfiguration i ett subnät och misslyckas tyst i ett annat.

Kontrollera rutttabellen som är kopplad till instansens subnät, inte bara VPC:ns huvudtabell. Subnätskopplingar åsidosätter huvudtabellen, och en inaktuell koppling är en vanlig orsak till att en fungerande konfiguration stannar efter en ombyggnad.

Håll IP-utgång och DNS åtskilda

Testa först en adressliteral, sedan ett namn, från samma klientapplikation. Om curl -4 https://checkip.amazonaws.com returnerar en offentlig adress men värdnamn misslyckas, fungerar tunneln och NAT-vägen och problemet är DNS: den pushade resolvern, klientens resolverstatus eller en säkerhetsgrupp som blockerar resolvern. Access Servers DNS-inställningar finns i samma Internet Access-område, men de färdas en annan kodväg.

Jämför den returnerade adressen med den utgång du avsåg. Är det instansens offentliga adress översätts trafiken av instansen; är det en NAT-gatewayadress används vägen genom det privata subnätet. Båda kan vara korrekta. Det du inte kan dra slutsatsen om är att en webbläsare på servern bevisar vidarebefordran för klienten.

Låt inte en kryssruta stänga utredningen

IPv6 är ett separat beslut. En full tunnel-policy för IPv4 säger ingenting om huruvida IPv6 bärs, blockeras eller läcker, och en klient med dubbla stackar kan fortsätta använda sin lokala IPv6-väg medan IPv4 går genom tunneln. Testa den adressfamilj du faktiskt bryr dig om, och besluta uttryckligen om den andra ska inaktiveras.

Till sist, testa det frånkopplade tillståndet. Valet full tunnel beskriver routningspolicyn medan du är ansluten, inte vad som händer när tunneln faller. Om kravet är att ingen trafik ska läcka ut utanför VPN, är det en fråga om kill-switch och brandvägg, och den kräver ett eget test i stället för en slutsats från rutttabellen.