Access Server-en tunel osoa EC2n: zergatik lauki batek ez duen nahikoa egiten

EC2 instantzia batean iturri eta helmugaren egiaztapena desaktibatzea da Access Server-en internet-irteerari buruzko galderei ematen zaien erantzunik errepikatuena, eta bere horretan ez du ezer egiten zure bezeroentzat. Egiaztapena AWSko birbidalketa-murrizketa da: instantziak onar ditzan egiten du bere helbidea ez den iturria edo helmuga duten paketeak. Ez dio Access Server bezeroari internet-trafikoa tuneletik bidaltzeko esaten, ez du gorako biderik sortzen eta ez du NAT gehitzen. Mitoa da laukia dela funtzioa.

Zer kontrolatzen duen egiaztapenak benetan

EC2 sare-interfaze bakoitzak berari zuzenduta ez dagoen trafikoa botatzen du, instantzia bideratzaile, NAT gailu edo VPN ate gisa ari bada eta egiaztapen hori desaktibatzen baduzu izan ezik. Desaktibatzeak birbidaltzeko baimena ematen du. Baimena ez da konfigurazioa: instantziak oraindik internet-ate edo NAT gailurako bidea behar du, VPCko bide-taulak oraindik dagokion sarrera behar du, segurtasun-taldeek oraindik fluxua baimendu behar dute, eta zerbitzariak oraindik itzulera-trafikoa itzuli edo bideratu behar du.

Egiaztatu uneko balioa aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck erabiliz ezer aldatu aurretik. Kontsolako aldatzen baduzu, aldatu instantziak beste batzuentzat birbidaltzen duelako, ez bezero batek internetera iristen ez duelako.

Access Server da bezeroaren bideratze-politikaren jabe

Access Server 3n, ireki Access Controls eta aurkitu Internet Access and DNS atala. Internet Gateway aukerak tunel osoa edo tunel zatitua eskaintzen ditu; tunel osoak bezeroari bere trafiko lehenetsia VPN barrura bideratzeko esaten dio, tunel zatituak internet-trafikoa bezeroaren tokiko bidean uzten du. Gorde eta aplikatu produktuaren lan-fluxuaren bidez, eta gero berriz konektatu probako bezero bat, politikak konexio unean bidaltzen baitira.

Bertsio zaharrek menu desberdinak erabiltzen dituzte eta Community OpenVPN konpilazio batzuek ez dute baliokiderik. Egiaztatu instalatutako bertsio nagusia existitzen ez den pantaila baten bila hasi aurretik. Gero egiaztatu bezeroak zer jaso zuen: tunel osoko profilek tuneletik bidezko bide lehenetsia instalatu behar du, eta tunel zatituko profilek ez.

Jarraitu paketeari tuneletik haratago

Bezeroak internet-trafikoa tunelera bidali ondoren, zerbitzariak birbidali behar du eta normalean itzuli. Access Serverrek bere NAT eta bideratze arauak kudeatzen ditu, beraz irakurri konfigurazio eraginkorra sortutako fitxategiei Community OpenVPN arauak gehitzea baino; kudeatu gabeko arauak gainidatzi edo talka egiten dute produktuaren hurrengo eguneratzean. sudo iptables -t nat -L -n -v edo nftablesen baliokideak erakusten du zer ari den benetan itzultzen.

AWSko aldea bide bereizia da. Sare azpi publiko bateko instantziak internet-atera zuzenean iristen da eta bere helbide publikoa edo IP elastikoa gordetzen du. Sare azpi pribatuko instantziak NAT atera edo NAT instantziarako bidea behar du, eta NAT gailuak bere bidea behar du internet-atera. Internet-atea VPCri lotzeak berez ez dio iturri pribatu bati itzulera-helbide publikorik ematen, eta horregatik Access Server-en konfigurazio berak sare azpi batean funtzionatzen du eta isilik huts egiten du bestean.

Egiaztatu instantziaren sare azpiari lotutako bide-taula, ez VPCko taula nagusia soilik. Sare azpien elkarteek taula nagusia gainditzen dute, eta elkarte zaharkitua ohiko arrazoia da funtzionatzen zuen konfigurazioa berreraikuntzaren ondoren gelditzeko.

Eduki IP irteera eta DNS bereizita

Probatu lehenik helbide literal bat, gero izen bat, bezeroaren aplikazio beretik. curl -4 https://checkip.amazonaws.com helbide publikoa itzultzen badu baina ostalari-izenek huts egiten badute, tunelak eta NAT bideak funtzionatzen dute eta arazoa DNS da: bidalitako resolverra, bezeroaren resolver egoera edo resolverra blokeatzen duen segurtasun-taldea. Access Server-en DNS ezarpenak Internet Access eremu berean daude, baina kode-bide desberdinetik doaz.

Konparatu itzulitako helbidea pentsatutako irteerarekin. Instantziaren helbide publikoa bada, instantziak itzultzen du trafikoa; NAT aterako helbidea bada, sare azpi pribatuko bidea erabiltzen ari da. Biak izan daitezke zuzenak. Ezin duzuna ondorioztatu da zerbitzariko nabigatzaile batek bezeroaren birbidalketa frogatzen duenik.

Ez utzi lauki batek ikerketa ixtea

IPv6 erabaki bereizia da. IPv4rako tunel osoko politikak ez du ezer esaten IPv6 eramaten, blokeatzen edo ihes egiten duen ala ez, eta pila bikoitzeko bezeroak bere tokiko IPv6 bidea erabiltzen jarrai dezake IPv4 tunelean dagoen bitartean. Probatu benetan axola zaizun helbide-familia, eta erabaki espresuki bestea desaktibatu behar den.

Azkenik, probatu deskonektatutako egoera. Tunel osoaren hautaketak konektatuta zaudenean indarrean dagoen bideratze-politika deskribatzen du, ez tunela erortzen denean zer gertatzen den. Baldintza VPNtik kanpora trafikorik ez ihes egitea bada, hori kill-switch eta suebaki kontua da, eta bere proba propioa behar du bide-taulatik ondorioztatu beharrean.