Volledige tunnel van Access Server op EC2: waarom één selectievakje niet genoeg is

Het uitschakelen van de bron- en bestemmingscontrole op een EC2-instantie is het meest herhaalde antwoord op vragen over de internetuitgang van Access Server, en op zichzelf doet het niets voor uw clients. De controle is een doorstuurbep erking van AWS: zij zorgt dat de instantie pakketten accepteert waarvan de bron of bestemming niet het eigen adres is. Zij vertelt de Access Server-client niet om internetverkeer door de tunnel te sturen, maakt geen route stroomopwaarts en voegt geen NAT toe. De mythe is dat het selectievakje de functie is.

Wat de controle werkelijk beheert

Elke EC2-netwerkinterface gooit verkeer weg dat niet aan haar is geadresseerd, tenzij de instantie als router, NAT-apparaat of VPN-gateway werkt en u die controle uitschakelt. Uitschakelen geeft toestemming om door te sturen. Toestemming is geen configuratie: de instantie heeft nog steeds een route naar een internetgateway of NAT-apparaat nodig, de VPC-routetabel heeft nog steeds de bijbehorende vermelding nodig, beveiligingsgroepen moeten de stroom nog steeds toestaan, en de server moet het retourverkeer nog steeds vertalen of routeren.

Controleer de huidige waarde met aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck voordat u iets wijzigt. Wijzigt u die in de console, wijzig die dan omdat de instantie voor anderen doorstuurt, niet omdat een client het internet niet bereikt.

Access Server bezit het routeringsbeleid van de client

Open in Access Server 3 Access Controls en zoek de sectie Internet Access and DNS. De keuze Internet Gateway biedt volledige of gesplitste tunnel; volledige tunnel zegt de client zijn standaardverkeer de VPN in te routeren, gesplitste tunnel laat internetverkeer op het lokale pad van de client. Sla op en pas toe via de werkstroom van het product en verbind daarna een testclient opnieuw, want het beleid wordt bij het verbinden geleverd.

Oudere releases gebruiken andere menu is en sommige Community OpenVPN-builds hebben geen gelijkwaardige besturing. Controleer de geïnstalleerde hoofdversie voordat u naar een scherm zoekt dat niet bestaat. Bevestig daarna wat de client ontving: een volledig-tunnelprofiel hoort een standaardroute door de tunnel te installeren, en een gesplitst-tunnelprofiel hoort dat niet te doen.

Volg het pakket na de tunnel

Zodra de client internetverkeer de tunnel in stuurt, moet de server het doorsturen en meestal vertalen. Access Server beheert zijn eigen NAT- en routeringsregels, dus lees de effectieve configuratie in plaats van Community OpenVPN-regels aan gegenereerde bestanden toe te voegen; onbeheerde regels worden overschreven of conflicteren bij de volgende productupdate. sudo iptables -t nat -L -n -v of het nftables-equivalent toont wat er werkelijk wordt vertaald.

De AWS-kant is een apart pad. Een instantie in een openbaar subnet bereikt een internetgateway rechtstreeks en behoudt het openbare adres of elastische IP. Een instantie in een privésubnet heeft een route naar een NAT-gateway of NAT-instantie nodig, en het NAT-apparaat heeft zijn eigen route naar de internetgateway nodig. Een internetgateway aan de VPC koppelen geeft op zichzelf geen enkele privébron een openbaar retour adres, en daarom werkt dezelfde Access Server-configuratie in het ene subnet en faalt stil in het andere.

Controleer de routetabel die aan het subnet van de instantie is gekoppeld, niet alleen de hoofdtabel van de VPC. Subnetkoppelingen gaan voor de hoofdtabel, en een verouderde koppeling is een veelvoorkomende reden dat een werkende configuratie na een herbouw stopt.

Houd IP-uitgang en DNS gescheiden

Test eerst een adresliteral, dan een naam, vanuit dezelfde clienttoepassing. Als curl -4 https://checkip.amazonaws.com een openbaar adres teruggeeft maar hostnamen falen, werken de tunnel en het NAT-pad en is het probleem DNS: de gepushte resolver, de resolverstatus van de client, of een beveiligingsgroep die de resolver blokkeert. De DNS-instellingen van Access Server staan in hetzelfde Internet Access-gebied, maar ze reizen via een ander codepad.

Vergelijk het teruggegeven adres met de uitgang die u bedoelde. Is het het openbare adres van de instantie, dan vertaalt de instantie het verkeer; is het een NAT-gatewayadres, dan wordt het pad via het privésubnet gebruikt. Beide kunnen juist zijn. Wat u niet kunt concluderen is dat een browser op de server de doorsturing voor de client bewijst.

Laat één selectievakje het onderzoek niet sluiten

IPv6 is een aparte beslissing. Een volledig-tunnelbeleid voor IPv4 zegt niets over of IPv6 wordt gedragen, geblokkeerd of lekt, en een client met dubbele stack kan zijn lokale IPv6-pad blijven gebruiken terwijl IPv4 door de tunnel gaat. Test de adresfamilie die u werkelijk aangaat, en beslis expliciet of de andere moet worden uitgeschakeld.

Test ten slotte de losgekoppelde toestand. De keuze volledige tunnel beschrijft het routeringsbeleid terwijl u verbonden bent, niet wat er gebeurt als de tunnel wegvalt. Als de eis is dat geen verkeer buiten de VPN ontsnapt, is dat een kwestie van kill-switch en firewall, en die vereist een eigen test in plaats van een afleiding uit de routetabel.