Full tunnel for Access Server på EC2: kvifor éin avkryssingsboks ikkje er nok

Å slå av kjelde- og målkontrollen på ein EC2-instans er det mest gjentatte svaret på spørsmål om internettutgangen til Access Server, og åleine gjer det ingenting for klientane dine. Kontrollen er ei videresendingsavgrensing i AWS: han får instansen til å godta pakkar der kjelda eller målet ikkje er hans eigen adresse. Han fortel ikkje Access Server-klienten å senda internettrafikk gjennom tunnelen, han opprettar ikkje ei rute oppover, og han legg ikkje til NAT. Myten er at avkryssingsboksen er funksjonen.

Kva kontrollen faktisk styrer

Kvart EC2-nettverksgrensesnitt kastar trafikk som ikkje er adressert til det, med mindre instansen fungerer som ruter, NAT-eining eller VPN-gateway og du slår av kontrollen. Å slå han av gjev løyve til å videresenda. Løyve er ikkje konfigurasjon: instansen treng framleis ei rute til ein internettgateway eller NAT-eining, VPC-rutetabellen treng framleis den samsvarande oppføringa, tryggingsgrupper må framleis tillate straumen, og tenaren må framleis omsetja eller ruta returtrafikken.

Kontroller gjeldande verdi med aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck før du endrar noko. Endrar du han i konsollen, gjer det fordi instansen videresender for andre, ikkje fordi ein klient ikkje når internett.

Access Server eig rutepolitikken til klienten

I Access Server 3 opnar du Access Controls og finn delen Internet Access and DNS. Valet Internet Gateway tilbyr full tunnel eller delt tunnel; full tunnel ber klienten ruta standardtrafikken inn i VPN, delt tunnel lèt internettrafikken bli på den lokale vegen til klienten. Lagre og bruk gjennom arbeidsflyten til produktet, og kople deretter til ein testklient på nytt, fordi politikken blir levert ved tilkoplingstidspunktet.

Eldre utgjevingar brukar andre menyar, og nokre Community OpenVPN-bygg har ingen tilsvarande kontroll. Kontroller den installerte hovudversjonen før du leitar etter ein skjerm som ikkje finst. Stadfest deretter kva klienten fekk: ein full tunnel-profil bør installera ei standardrute gjennom tunnelen, og ein delt tunnel-profil bør ikkje gjera det.

Spor pakken etter tunnelen

Når klienten sender internettrafikk inn i tunnelen, må tenaren videresenda han og vanlegvis omsetja han. Access Server styrer sine eigne NAT- og ruteregler, så les den effektive konfigurasjonen i staden for å leggja Community OpenVPN-reglar til genererte filer; uregulerte reglar blir overskrivne eller kjem i konflikt ved neste produktoppdatering. sudo iptables -t nat -L -n -v eller nftables-motstykket viser kva som faktisk blir omsett.

AWS-sida er ein eigen veg. Ein instans i eit offentleg subnett når ein internettgateway direkte og held på den offentlege adressa eller den elastiske IP-en. Ein instans i eit privat subnett treng ei rute til ein NAT-gateway eller NAT-instans, og NAT-eininga treng si eiga rute til internettgatewayen. Å knyta ein internettgateway til VPC gjev ikkje i seg sjølv noka privat kjelde ein offentleg returadresse, og difor verkar same Access Server-oppsett i eitt subnett og feilar lydlaust i eit anna.

Kontroller rutetabellen som er knytt til subnettet til instansen, ikkje berre hovudtabellen i VPC. Subnett-tilknytingar overstyrer hovudtabellen, og ei utdatert tilknyting er ein vanleg grunn til at ein fungerande konfigurasjon stoggar etter ein ombygging.

Hald IP-utgang og DNS skilde

Test først ein adresseliteral, deretter eit namn, frå same klientprogram. Viss curl -4 https://checkip.amazonaws.com returnerer ei offentleg adresse men vertsnamn feilar, verkar tunnelen og NAT-vegen, og problemet er DNS: den pusha resolveren, resolvertilstanden til klienten, eller ei tryggingsgruppe som blokkerer resolveren. DNS-innstillingane til Access Server ligg i same Internet Access-område, men dei reiser ein annan kodeveg.

Samanlikn den returnerte adressa med utgangen du hadde tenkt. Er det den offentlege adressa til instansen, blir trafikken omsett av instansen; er det ei NAT-gatewayadresse, blir vegen gjennom det private subnettet brukt. Begge kan vera rette. Det du ikkje kan slutta deg til, er at ein nettlesar på tenaren provar videresendinga for klienten.

Ikkje lat éin avkryssingsboks lukka undersøkinga

IPv6 er ei eiga avgjerd. Ein full tunnel-politikk for IPv4 seier ingenting om IPv6 blir boren, blokkert eller lekk, og ein klient med dobbel stabel kan halda fram med å bruka den lokale IPv6-vegen sin medan IPv4 går gjennom tunnelen. Test adressefamilien du faktisk bryr deg om, og avgjer uttrykkeleg om den andre skal deaktiverast.

Til slutt, test den fråkopla tilstanden. Eit full tunnel-val beskriv rutepolitikken medan du er tilkopla, ikkje kva som skjer når tunnelen fell. Viss kravet er at ingen trafikk slepp ut utanfor VPN, er det eit kill-switch- og brannmurspørsmål, og det treng si eiga prøving i staden for ei slutning frå rutetabellen.