Plena tunelo de Access Server sur EC2: kial un markobutono ne sufiĉas

Malŝalti la kontrolon de fonto kaj celo sur EC2-kopio estas la plej ofte ripetata respondo al demandoj pri la reteliro de Access Server, kaj sole ĝi faras nenion por viaj klientoj. La kontrolo estas plusenda limigo de AWS: ĝi igas la kopion akcepti pakaĵojn kies fonto aŭ celo ne estas ĝia propra adreso. Ĝi ne diras al la kliento de Access Server sendi rettrafikon tra la tunelo, ĝi ne kreas supran vojon kaj ĝi ne aldonas NAT. La mito estas ke la markobutono estas la funkcio.

Kion la kontrolo efektive regas

Ĉiu reta interfaco de EC2 forĵetas trafikon ne adresitan al ĝi, krom se la kopio agas kiel enkursigilo, NAT-aparato aŭ VPN-pordego kaj vi malŝaltas tiun kontrolon. Malŝalti ĝin donas permeson plusendi. Permeso ne estas agordo: la kopio ankoraŭ bezonas vojon al interreta pordego aŭ NAT-aparato, la vojtaĵtabelo de la VPC ankoraŭ bezonas la kongruan rikordon, sekurecgrupoj ankoraŭ devas permesi la fluon, kaj la servilo ankoraŭ devas traduki aŭ enkursigi la revenan trafikon.

Kontrolu la nunan valoron per aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck antaŭ ol ŝanĝi ion. Se vi ŝanĝas ĝin en la konzolo, ŝanĝu ĝin ĉar la kopio plusendas por aliuloj, ne ĉar kliento ne atingas la interreton.

La enkursiga politiko de la kliento apartenas al Access Server

En Access Server 3 malfermu Access Controls kaj trovu la sekcion Internet Access and DNS. La elekto Internet Gateway proponas plenan aŭ dividitan tunelon; plena tunelo diras al la kliento enkursigi sian defaŭltan trafikon en la VPN, dividita tunelo lasas la rettrafikon sur la loka vojo de la kliento. Konservu kaj apliku tra la laborfluo de la produkto, poste rekonektu testan klienton, ĉar la politiko estas liverata ĉe la konekta momento.

Pli malnovaj eldonoj uzas aliajn menuojn, kaj iuj Community-konstruaĵoj de OpenVPN ne havas ekvivalentan regilon. Kontrolu la instalitan ĉefversion antaŭ ol serĉi ekranon kiu ne ekzistas. Poste konfirmu kion la kliento ricevis: plentunela profilo devus instali defaŭltan vojon tra la tunelo, kaj dividittunela profilo ne devus.

Spuru la pakaĵon post la tunelo

Kiam la kliento sendas rettrafikon en la tunelon, la servilo devas plusendi ĝin kaj kutime traduki ĝin. Access Server administras siajn proprajn regulojn pri NAT kaj enkursigo, do legu la efektivan agordon anstataŭ aldoni regulojn de Community OpenVPN al generitaj dosieroj; neadministritaj reguloj estas anstataŭigataj aŭ kolizias ĉe la sekva produkta ĝisdatigo. sudo iptables -t nat -L -n -v aŭ la nftables-ekvivalento montras kio efektive tradukiĝas.

La AWS-flanko estas aparta vojo. Kopio en publika subreto atingas interretan pordegon rekte kaj konservas sian publikan adreson aŭ elastan IP. Kopio en privata subreto bezonas vojon al NAT-pordego aŭ NAT-kopio, kaj la NAT-aparato bezonas sian propran vojon al la interreta pordego. Aldoni interretan pordegon al la VPC per si mem donas al neniu privata fonto publikan revenan adreson, tial la sama agordo de Access Server funkcias en unu subreto kaj silente malsukcesas en alia.

Kontrolu la vojtaĵtabelon ligitan al la subreto de la kopio, ne nur la ĉefan tabelon de la VPC. Subretaj ligoj superas la ĉefan tabelon, kaj malnova ligo estas ofta kialo ke funkcianta agordo haltas post rekonstruo.

Tenu la IP-eliron kaj DNS aparte

Testu unue adresan literalon, poste nomon, el la sama klienta aplikaĵo. Se curl -4 https://checkip.amazonaws.com redonas publikan adreson sed gastigantaj nomoj malsukcesas, la tunelo kaj la NAT-vojo funkcias kaj la problemo estas DNS: la puŝita solvilo, la solvila stato de la kliento, aŭ sekurecgrupo blokanta la solvilon. La DNS-agordoj de Access Server troviĝas en la sama Internet Access-regiono, sed ili vojaĝas per alia koda vojo.

Komparu la redonitan adreson kun la eliro kiun vi intencis. Se ĝi estas la publika adreso de la kopio, la trafikon tradukas la kopio; se ĝi estas adreso de NAT-pordego, la vojo de la privata subreto estas uzata. Ambaŭ povas esti ĝustaj. Kion vi ne povas konkludi estas ke retumilo sur la servilo pruvas plusendadon por la kliento.

Ne lasu unu markobutonon fermi la esploron

IPv6 estas aparta decido. Plentunela politiko por IPv4 diras nenion pri tio ĉu IPv6 estas portata, blokata aŭ likata, kaj duobla-staka kliento povas daŭre uzi sian lokan IPv6-vojon dum IPv4 iras tra la tunelo. Testu la adresan familion pri kiu vi efektive zorgas, kaj eksplicite decidu ĉu la alia devus esti malŝaltita.

Fine, testu la malkonektitan staton. Plentunela elekto priskribas la enkursigan politikon dum vi estas konektita, ne kio okazas kiam la tunelo falas. Se la postulo estas ke neniu trafiko eskapu ekster la VPN, tio estas demando pri kill-switch kaj fajroŝirmilo, kaj ĝi bezonas sian propran teston anstataŭ konkludon el la vojtaĵtabelo.