Fuld tunnel til Access Server på EC2: hvorfor ét afkrydsningsfelt ikke er nok

At slå kilde- og destinationskontrol fra på en EC2-instans er det mest gentagne svar på spørgsmål om Access Servers internetudgang, og i sig selv gør det intet for dine klienter. Kontrollen er en videresendelsesbegrænsning i AWS: den får instansen til at acceptere pakker, hvis kilde eller destination ikke er dens egen adresse. Den fortæller ikke Access Server-klienten at sende internettrafik gennem tunnelen, den opretter ikke en rute opad, og den tilføjer ikke NAT. Myten er, at afkrydsningsfeltet er funktionen.

Hvad kontrollen faktisk styrer

Hver EC2-netværksgrænseflade kasserer trafik, der ikke er adresseret til den, medmindre instansen fungerer som router, NAT-enhed eller VPN-gateway, og du slår den kontrol fra. At slå den fra giver tilladelse til at videresende. Tilladelse er ikke konfiguration: instansen har stadig brug for en rute til en internetgateway eller NAT-enhed, VPC-rutetabellen har stadig brug for den matchende post, sikkerhedsgrupper skal stadig tillade flowet, og serveren skal stadig oversætte eller route returtrafikken.

Kontroller den aktuelle værdi med aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck, før du ændrer noget. Hvis du ændrer den i konsollen, så gør det, fordi instansen videresender for andre, ikke fordi en klient ikke kan nå internettet.

Access Server ejer klientens rutepolitik

I Access Server 3 åbner du Access Controls og finder afsnittet Internet Access and DNS. Valget Internet Gateway tilbyder fuld tunnel eller delt tunnel; fuld tunnel fortæller klienten at route sin standardtrafik ind i VPN’en, delt tunnel lader internettrafikken blive på klientens lokale vej. Gem og anvend gennem produktets arbejdsgang, og genopret derefter forbindelsen til en testklient, fordi politikken leveres ved forbindelsestidspunktet.

Ældre udgivelser bruger andre menuer, og nogle Community OpenVPN-builds har ingen tilsvarende kontrol. Kontroller den installerede hovedversion, før du leder efter en skærm, der ikke findes. Bekræft derefter, hvad klienten fik: en fuld tunnel-profil bør installere en standardrute gennem tunnelen, og en delt tunnel-profil bør ikke.

Følg pakken efter tunnelen

Når klienten sender internettrafik ind i tunnelen, skal serveren videresende den og normalt oversætte den. Access Server styrer sine egne NAT- og routingregler, så læs den effektive konfiguration i stedet for at tilføje Community OpenVPN-regler til genererede filer; uregulerede regler bliver overskrevet eller kommer i konflikt ved den næste produktopdatering. sudo iptables -t nat -L -n -v eller nftables-modstykket viser, hvad der faktisk oversættes.

AWS-siden er en separat vej. En instans i et offentligt subnet når en internetgateway direkte og beholder sin offentlige adresse eller elastiske IP. En instans i et privat subnet har brug for en rute til en NAT-gateway eller NAT-instans, og NAT-enheden har brug for sin egen rute til internetgatewayen. At knytte en internetgateway til VPC’en giver ikke i sig selv nogen privat kilde en offentlig returadresse, og derfor virker det samme Access Server-opsætning i et subnet og fejler lydløst i et andet.

Kontroller rutetabellen, der er knyttet til instansens subnet, ikke kun VPC’ens hovedtabel. Subnet-tilknytninger tilsidesætter hovedtabellen, og en forældet tilknytning er en almindelig grund til, at en fungerende konfiguration stopper efter en genopbygning.

Hold IP-udgang og DNS adskilt

Test først en adresseliteral, derefter et navn, fra den samme klientapplikation. Hvis curl -4 https://checkip.amazonaws.com returnerer en offentlig adresse, men værtsnavne fejler, virker tunnelen og NAT-vejen, og problemet er DNS: den push’ede resolver, klientens resolver-tilstand eller en sikkerhedsgruppe, der blokerer resolveren. Access Servers DNS-indstillinger ligger i samme Internet Access-område, men de rejser en anden kodevej.

Sammenlign den returnerede adresse med den udgang, du havde til hensigt. Er det instansens offentlige adresse, oversættes trafikken af instansen; er det en NAT-gatewayadresse, bruges det private subnet. Begge kan være korrekte. Det, du ikke kan konkludere, er, at en browser på serveren beviser videresendelse for klienten.

Lad ikke ét afkrydsningsfelt lukke undersøgelsen

IPv6 er en separat beslutning. En fuld tunnel-politik for IPv4 siger intet om, hvorvidt IPv6 bæres, blokeres eller lækker, og en dobbeltstak-klient kan fortsætte med at bruge sin lokale IPv6-vej, mens IPv4 går gennem tunnelen. Test den adressefamilie, du faktisk bekymrer dig om, og beslut udtrykkeligt, om den anden skal deaktiveres.

Til sidst skal du teste den afbrudte tilstand. Et fuld tunnel-valg beskriver rutepolitikken, mens du er forbundet, ikke hvad der sker, når tunnelen falder. Hvis kravet er, at ingen trafik slipper ud uden for VPN’en, er det et kill-switch- og firewall-spørgsmål, og det kræver sin egen test i stedet for en slutning fra rutetabellen.