Access Server-voltonnel op EC2: waarom een merkblokkie nie genoeg is nie

Om bron- en bestemmingskontrole op ’n EC2-instansie af te skakel, is die antwoord wat die meeste herhaal word op vrae oor Access Server se internetuitgang, en op sigself doen dit niks vir jou kliënte nie. Die kontrole is ’n AWS-deurstuurbeperking: dit laat die instansie pakkette aanvaar waarvan die bron of bestemming nie sy eie adres is nie. Dit sê nie vir die Access Server-kliënt om internetverkeer deur die tonnel te stuur nie, dit skep nie ’n roete opstroom nie en dit voeg nie NAT by nie. Die mite is dat die merkblokkie die funksie is.

Wat die kontrole werklik beheer

Elke EC2-netwerkkoppelvlak laat verkeer val wat nie aan hom gerig is nie, tensy die instansie as ’n roeteerder, NAT-toestel of VPN-gwey optree en jy daardie kontrole afskakel. Om dit af te skakel, gee toestemming om deur te stuur. Toestemming is nie konfigurasie nie: die instansie het steeds ’n roete na ’n internetgwey of NAT-toestel nodig, die VPC-roetetabel het steeds die ooreenstemmende inskrywing nodig, sekuriteitsgroepe moet steeds die vloei toelaat, en die bediener moet steeds die terugkeerverkeer vertaal of roeteer.

Kontroleer die huidige waarde met aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck voordat jy enigiets verander. As jy dit in die konsole verander, verander dit omdat die instansie vir ander deurstuur, nie omdat ’n kliënt nie die internet kan bereik nie.

Access Server besit die kliëntroeteringsbeleid

In Access Server 3, maak Access Controls oop en vind die afdeling Internet Access and DNS. Die Internet Gateway-keuse bied voltonnel of gesplete tonnel; voltonnel sê vir die kliënt om sy verstekverkeer in die VPN in te roeteer, gesplete tonnel laat internetverkeer op die kliënt se plaaslike pad. Stoor en pas toe deur die produk se werkvloei, en herverbind dan ’n toetskliënt, want die beleid word by verbindingstyd afgelewer.

Ouer weergawes gebruik ander kieslyste en sommige Community OpenVPN-boue het geen ekwivalente beheer nie. Kontroleer die geïnstalleerde hoofweergawe voordat jy na ’n skerm soek wat nie bestaan nie. Bevestig dan wat die kliënt ontvang het: ’n voltonnelprofiel behoort ’n verstekroete deur die tonnel te installeer, en ’n gesplete-tonnelprofiel behoort dit nie te doen nie.

Volg die pakket ná die tonnel

Sodra die kliënt internetverkeer in die tonnel stuur, moet die bediener dit deurstuur en gewoonlik vertaal. Access Server bestuur sy eie NAT- en roeteringsreëls, so lees die effektiewe konfigurasie eerder as om Community OpenVPN-reëls by gegenereerde lêers te voeg; onbestuurde reëls word oorskryf of bots by die volgende produkopdatering. sudo iptables -t nat -L -n -v of die nftables-ekwivalent wys wat werklik vertaal.

Die AWS-kant is ’n aparte pad. ’n Instansie in ’n openbare subnet bereik ’n internetgwey direk en behou sy openbare adres of elastiese IP. ’n Instansie in ’n private subnet het ’n roete na ’n NAT-gwey of NAT-instansie nodig, en die NAT-toestel het sy eie roete na die internetgwey nodig. Om ’n internetgwey aan die VPC te koppel, gee op sigself geen private bron ’n openbare terugkeeradres nie; daarom werk dieselfde Access Server-opstelling in een subnet en misluk dit stilweg in ’n ander.

Kontroleer die roetetabel wat met die instansie se subnet geassosieer is, nie net die VPC se hooftabel nie. Subnetassosiasies oorheers die hooftabel, en ’n verouderde assosiasie is ’n algemene rede waarom ’n werkende konfigurasie ná ’n herbou stop.

Hou IP-uitgang en DNS apart

Toets eers ’n adresliteraal en dan ’n naam, vanuit dieselfde kliënttoepassing. As curl -4 https://checkip.amazonaws.com ’n openbare adres teruggee maar gasheername misluk, werk die tonnel en die NAT-pad en is die probleem DNS: die gestuurde resolver, die kliënt se resolvertoestand, of ’n sekuriteitsgroep wat die resolver blokkeer. Die Access Server se DNS-instellings woon in dieselfde Internet Access-gebied, maar hulle reis op ’n ander kodepad.

Vergelyk die teruggegewe adres met die uitgang wat jy bedoel het. As dit die instansie se openbare adres is, word verkeer deur die instansie vertaal; as dit ’n NAT-gwey-adres is, word die private-subnetpad gebruik. Enigeen kan korrek wees. Wat jy nie kan aflei nie, is dat ’n blaaier op die bediener kliëntdeurstuur bewys.

Moenie een merkblokkie die ondersoek laat afsluit nie

IPv6 is ’n aparte besluit. ’n Voltonnelbeleid vir IPv4 sê niks oor of IPv6 gedra, geblokkeer of gelek word nie, en ’n dubbelstapel-kliënt kan sy plaaslike IPv6-pad bly gebruik terwyl IPv4 deur die tonnel gaan. Toets die adresfamilie waarvoor jy werklik omgee, en besluit uitdruklik of die ander een afgeskakel moet word.

Toets laastens die ontkoppelde toestand. ’n Voltonnelkeuse beskryf die roeteringsbeleid terwyl jy gekoppel is, nie wat gebeur wanneer die tonnel val nie. As die vereiste is dat geen verkeer buite die VPN ontsnap nie, is dit ’n doodskakelaar- en brandmuurvraag, en dit het sy eie toets nodig eerder as ’n afleiding uit die roetetabel.