Full tunnel for Access Server på EC2: hvorfor én avmerkingsboks ikke er nok

Å slå av kilde- og destinasjonskontrollen på en EC2-instans er det mest gjentatte svaret på spørsmål om Access Servers internettutgang, og alene gjør det ingenting for klientene dine. Kontrollen er en videresendingsbegrensning i AWS: den får instansen til å godta pakker der kilden eller destinasjonen ikke er dens egen adresse. Den forteller ikke Access Server-klienten å sende internettrafikk gjennom tunnelen, den oppretter ikke en rute oppover, og den legger ikke til NAT. Myten er at avmerkingsboksen er funksjonen.

Hva kontrollen faktisk styrer

Hver EC2-nettverksgrensesnitt forkaster trafikk som ikke er adressert til det, med mindre instansen fungerer som ruter, NAT-enhet eller VPN-gateway og du slår av kontrollen. Å slå den av gir tillatelse til å videresende. Tillatelse er ikke konfigurasjon: instansen trenger fortsatt en rute til en internettgateway eller NAT-enhet, VPC-rutetabellen trenger fortsatt den matchende oppføringen, sikkerhetsgrupper må fortsatt tillate flyten, og serveren må fortsatt oversette eller rute returtrafikken.

Kontroller gjeldende verdi med aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck før du endrer noe. Hvis du endrer den i konsollen, gjør det fordi instansen videresender for andre, ikke fordi en klient ikke når internett.

Access Server eier klientens rutepolicy

I Access Server 3 åpner du Access Controls og finner delen Internet Access and DNS. Valget Internet Gateway tilbyr full tunnel eller delt tunnel; full tunnel ber klienten rute standardtrafikken inn i VPN, delt tunnel lar internettrafikken bli på klientens lokale vei. Lagre og bruk gjennom produktets arbeidsflyt, og koble deretter til en testklient på nytt, fordi policyen leveres ved tilkoblingstidspunktet.

Eldre utgivelser bruker andre menyer, og noen Community OpenVPN-bygg har ingen tilsvarende kontroll. Kontroller den installerte hovedversjonen før du leter etter en skjerm som ikke finnes. Bekreft deretter hva klienten fikk: en full tunnel-profil bør installere en standardrute gjennom tunnelen, og en delt tunnel-profil bør ikke gjøre det.

Spor pakken etter tunnelen

Når klienten sender internettrafikk inn i tunnelen, må serveren videresende den og vanligvis oversette den. Access Server administrerer sine egne NAT- og ruteregler, så les den effektive konfigurasjonen i stedet for å legge Community OpenVPN-regler til genererte filer; uregulerte regler overskrives eller kommer i konflikt ved neste produktoppdatering. sudo iptables -t nat -L -n -v eller nftables-motstykket viser hva som faktisk oversettes.

AWS-siden er en egen vei. En instans i et offentlig subnett når en internettgateway direkte og beholder sin offentlige adresse eller elastiske IP. En instans i et privat subnett trenger en rute til en NAT-gateway eller NAT-instans, og NAT-enheten trenger sin egen rute til internettgatewayen. Å knytte en internettgateway til VPC gir ikke i seg selv noen privat kilde en offentlig returadresse, og derfor virker samme Access Server-oppsett i ett subnett og feiler lydløst i et annet.

Kontroller rutetabellen som er knyttet til instansens subnett, ikke bare VPC-ens hovedtabell. Subnett-tilknytninger overstyrer hovedtabellen, og en utdatert tilknytning er en vanlig grunn til at en fungerende konfigurasjon stopper etter en gjenoppbygging.

Hold IP-utgang og DNS atskilt

Test først en adresseliteral, deretter et navn, fra samme klientapplikasjon. Hvis curl -4 https://checkip.amazonaws.com returnerer en offentlig adresse men vertsnavn feiler, virker tunnelen og NAT-veien, og problemet er DNS: den push-ede resolveren, klientens resolver-tilstand eller en sikkerhetsgruppe som blokkerer resolveren. Access Servers DNS-innstillinger ligger i samme Internet Access-område, men de reiser en annen kodevei.

Sammenlign den returnerte adressen med utgangen du hadde tenkt. Er det instansens offentlige adresse, oversettes trafikken av instansen; er det en NAT-gatewayadresse, brukes veien gjennom det private subnettet. Begge kan være riktige. Det du ikke kan konkludere, er at en nettleser på serveren beviser videresending for klienten.

Ikke la én avmerkingsboks lukke undersøkelsen

IPv6 er en egen beslutning. En full tunnel-policy for IPv4 sier ingenting om hvorvidt IPv6 bæres, blokkeres eller lekker, og en klient med dobbel stabel kan fortsette å bruke sin lokale IPv6-vei mens IPv4 går gjennom tunnelen. Test adressefamilien du faktisk bryr deg om, og bestem uttrykkelig om den andre skal deaktiveres.

Til slutt, test den frakoblede tilstanden. Et full tunnel-valg beskriver rutepolicyen mens du er tilkoblet, ikke hva som skjer når tunnelen faller. Hvis kravet er at ingen trafikk slipper ut utenfor VPN, er det et kill-switch- og brannmurspørsmål, og det trenger sin egen test i stedet for en slutning fra rutetabellen.