Volltunnel vum Access Server op EC2: firwat eng eenzeg Këscht net duergeet
D’Quell- an Destinatiounskontroll op EC2 auszeschalten ass eng Forwarding-Korrektur, keng Internetpolitik fir de Client. Setzt den Volltunnel am Access Server an verfollegt duerno de AWS-Ausgangspad.
D’Quell- an Destinatiounskontroll op enger EC2-Instanz auszeschalten ass déi am heefegsten widderholl Äntwert op Froen zum Internetausgang vum Access Server, an eleng mécht si näischt fir Är Clienten. D’Kontroll ass eng AWS-Forwarding-Beschränkung: si mécht datt d’Instanz Pakete akzeptéiert, deenen hir Quell oder Destinatioun net hir eege Adress ass. Si seet dem Client net, den Internettrafic duerch den Tunnel ze schécken, si schaaft keng Route no uewen a si setzt keen NAT derbäi. De Mythos ass, datt d’Këscht d’Funktioun ass.
Wat d’Kontroll tatsächlech steiert
All EC2-Netzwierkinterface verwëft Trafic, deen net un et adresséiert ass, ausser d’Instanz handelt als Router, NAT-Apparat oder VPN-Gateway an Dir schalt dës Kontroll aus. D’Ausschalten gëtt d’Erlaabnis fir weiderzeschécken. Erlaabnis ass keng Konfiguratioun: d’Instanz brauch nach ëmmer eng Route zu engem Internetgateway oder NAT-Apparat, d’Routentabelle vum VPC brauch nach ëmmer den entspriechende Benotz, d’Sécherheetsgruppen mussen de Floss nach ëmmer erlaben, an de Server muss den Zrécktrafic nach ëmmer iwwersetzen oder routen.
Préift de momentane Wäert mat aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck ier Dir eppes ännert. Wann Dir en an der Konsole ännert, ännert en well d’Instanz fir anerer weiderschéckt, net well e Client den Internet net erreecht.
D’Routingspolitik vum Client gehéiert dem Access Server
Am Access Server 3 öffnet Access Controls a fannt d’Sektioun Internet Access and DNS. D’Auswiel Internet Gateway bitt Volltunnel oder gedeelten Tunnel; de Volltunnel seet dem Client säi Standardtrafic an de VPN ze router, de gedeelten Tunnel léisst den Internettrafic um lokale Pad vum Client. Späichert a setzt iwwer de Workflow vum Produkt ëm, reconnectéiert duerno e Testclient, well d’Politik beim Verbindungszäitpunkt geliwwert gëtt.
Méi al Versioune benotzen aner Menüen an e puer Community OpenVPN-Builden hunn keng gläichwäerteg Kontroll. Préift déi installéiert Haaptversioun ier Dir en Ecran sicht, deen et net gëtt. Bestätegt duerno wat de Client kritt huet: e Volltunnelprofil soll eng Standardroute duerch den Tunnel installéieren, an e gedeelte Tunnelprofil soll dat net maachen.
Verfollegt de Paket no dem Tunnel
Soubal de Client Internettrafic an den Tunnel schéckt, muss de Server en weiderschécken an normalerweis iwwersetzen. Den Access Server geréiert seng eege NAT- a Routingregelen, also liest d’effektiv Konfiguratioun amplaz Community-OpenVPN-Regelen un déi generéiert Fichieren unzehänken; ongeréiert Regele ginn beim nächsten Produktupdate iwwerschriwwen oder gerode sech a Konflikt. sudo iptables -t nat -L -n -v oder d’nftables-Äquivalent weist wat tatsächlech iwwersat gëtt.
D’AWS-Säit ass en eegene Pad. Eng Instanz an engem ëffentlechen Subnetz erreecht en Internetgateway direkt a behält seng ëffentlech Adress oder hir elastesch IP. Eng Instanz an engem private Subnetz brauch eng Route zu engem NAT-Gateway oder enger NAT-Instanz, an den NAT-Apparat brauch seng eege Route zum Internetgateway. En Internetgateway un de VPC ze hänken gëtt eleng kenger private Quell eng ëffentlech Zréckadress, dofir fonctionnéiert déiselwecht Access-Server-Konfiguratioun an engem Subnetz an an engem aneren heescht et einfach net.
Préift d’Routentabelle déi mam Subnetz vun der Instanz verbonnen ass, net nëmmen d’Haapttabelle vum VPC. Subnetzassociatiounen iwwerstiere d’Haapttabelle, an eng veroudert Associatioun ass eng heefeg Ursaach dofir, datt eng funktionéierend Konfiguratioun no engem Neibau stoppt.
Halt den IP-Ausgang an DNS getrennt
Testet als éischt en Adressliteral, duerno en Numm, aus der selwechter Clientapplikatioun. Wann curl -4 https://checkip.amazonaws.com eng ëffentlech Adress zréckgëtt awer d’Hostnimm feelen, funktionéieren den Tunnel an de NAT-Pad an de Problem ass DNS: de geschéckten Resolver, den Zoustand vum Resolver beim Client, oder eng Sécherheetsgrupp déi de Resolver blockéiert. D’DNS-Astellungen vum Access Server sinn am selwechten Internet Access-Beräich, awer si reesen en aneren Codepad.
Vergläicht d’zréckgeliwwert Adress mat dem Ausgang deen Dir virgesinn hutt. Wann et d’ëffentlech Adress vun der Instanz ass, gëtt den Trafic vun der Instanz iwwersat; wann et eng NAT-Gatewayadress ass, gëtt de Pad iwwer de private Subnetz benotzt. Béides ka richteg sinn. Wat Dir net kënnt schléissen ass, datt e Browser um Server d’Weiderschécke fir de Client beweist.
Loosst eng eenzeg Këscht d’Enquête net ofschléissen
IPv6 ass eng eegen Entscheedung. Eng Volltunnelpolitik fir IPv4 seet näischt doriwwer, ob IPv6 gedroe, blockéiert oder geleekt gëtt, an e Client mat duebelem Stack ka säi lokale IPv6-Pad weider benotzen während IPv4 am Tunnel ass. Test d’Adressfamill déi Iech wierklech wichteg ass, an entscheet ausdrécklech ob déi aner soll ausgeschalt ginn.
Zum Schluss test d’ofgetrennte Zoustand. D’Auswiel vum Volltunnel beschreift d’Routingpolitik während Dir verbonnen sidd, net wat geschitt wann den Tunnel fällt. Wann d’Ufuerderung ass datt keen Trafic aus dem VPN erauskënnt, ass dat eng Fro vu Kill-Switch a Firewall, an et brauch seng eege Test amplaz eng Ofleedung aus der Routentabelle.