Buong tunnel ng Access Server sa EC2: bakit hindi sapat ang isang checkbox

Ang pag-disable ng source at destination check sa isang EC2 instance ang pinaka-paulit-ulit na sagot sa mga tanong tungkol sa internet egress ng Access Server, at mag-isa ay wala itong ginagawa para sa iyong mga kliyente. Ang check ay isang hadlang sa forwarding ng AWS: pinapayagan nito ang instance na tumanggap ng mga packet na ang source o destination ay hindi ang sarili nitong address. Hindi nito sinasabi sa kliyente ng Access Server na ipadala ang internet traffic sa tunnel, hindi ito gumagawa ng ruta pataas, at hindi ito nagdaragdag ng NAT. Ang mito ay ang checkbox mismo ang feature.

Ano talaga ang kinokontrol ng check

Bawat EC2 network interface ay nagtatapon ng traffic na hindi nakadirekta dito, maliban kung ang instance ay gumaganap na router, NAT device o VPN gateway at i-disable mo ang check na iyon. Ang pag-disable nito ay nagbibigay ng pahintulot na mag-forward. Ang pahintulot ay hindi configuration: kailangan pa rin ng instance ng ruta sa isang internet gateway o NAT device, kailangan pa rin ng VPC route table ng tugmang entry, dapat pa ring payagan ng security groups ang daloy, at kailangan pa ring isalin o i-route ng server ang return traffic.

Suriin ang kasalukuyang halaga gamit ang aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck bago magbago ng anuman. Kung babaguhin mo ito sa console, baguhin mo dahil nagfo-forward ang instance para sa iba, hindi dahil hindi maabot ng kliyente ang internet.

Pag-aari ng Access Server ang routing policy ng kliyente

Sa Access Server 3, buksan ang Access Controls at hanapin ang seksyong Internet Access and DNS. Ang pagpipilian sa Internet Gateway ay nag-aalok ng buong tunnel o split tunnel; ang buong tunnel ay nagsasabi sa kliyente na i-route ang default traffic nito sa VPN, ang split tunnel ay iniiwan ang internet traffic sa lokal na landas ng kliyente. I-save at ilapat sa pamamagitan ng workflow ng produkto, pagkatapos muling ikonekta ang test client, dahil ang patakaran ay inihahatid sa oras ng koneksyon.

Gumagamit ang mga lumang release ng ibang mga menu at ang ilang Community OpenVPN build ay walang katumbas na kontrol. Suriin ang naka-install na major version bago maghanap ng screen na wala naman. Pagkatapos kumpirmahin kung ano ang natanggap ng kliyente: ang buong tunnel profile ay dapat mag-install ng default route sa tunnel, at ang split tunnel profile ay hindi dapat.

Subaybayan ang packet pagkatapos ng tunnel

Kapag ipinadala ng kliyente ang internet traffic sa tunnel, dapat itong i-forward ng server at karaniwang isalin. Pinamamahalaan ng Access Server ang sarili nitong NAT at routing rules, kaya basahin ang epektibong configuration sa halip na magdagdag ng Community OpenVPN rules sa mga nabuong file; ang mga hindi pinamamahalaang rule ay na-overwrite o nagkakasalungat sa susunod na update ng produkto. Ipinapakita ng sudo iptables -t nat -L -n -v o ang katumbas sa nftables kung ano ang aktwal na isinasalin.

Ang panig ng AWS ay hiwalay na landas. Ang instance sa public subnet ay direktang nakakaabot sa internet gateway at pinapanatili ang public address o elastic IP nito. Ang instance sa private subnet ay nangangailangan ng ruta sa NAT gateway o NAT instance, at ang NAT device ay nangangailangan ng sarili nitong ruta sa internet gateway. Ang pagkabit ng internet gateway sa VPC ay hindi mismo nagbibigay ng public return address sa anumang private source, kaya gumagana ang parehong setup ng Access Server sa isang subnet at tahimik na nabigo sa isa pa.

Suriin ang route table na nauugnay sa subnet ng instance, hindi lamang ang pangunahing table ng VPC. Ang mga subnet association ay nangingibabaw sa pangunahing table, at ang lumang association ay karaniwang dahilan kung bakit humihinto ang gumaganang configuration pagkatapos ng muling pagbuo.

Paghiwalayin ang IP egress at DNS

Subukan muna ang address literal, pagkatapos ang pangalan, mula sa parehong client application. Kung nagbabalik ng public address ang curl -4 https://checkip.amazonaws.com ngunit nabigo ang mga hostname, gumagana ang tunnel at NAT path at ang problema ay DNS: ang ipinadalang resolver, ang resolver state ng kliyente, o isang security group na humaharang sa resolver. Ang mga setting ng DNS ng Access Server ay nasa parehong Internet Access area, ngunit dumadaan sila sa ibang code path.

Ihambing ang ibinalik na address sa exit na nilalayon mo. Kung ito ang public address ng instance, isinasalin ng instance ang traffic; kung ito ay address ng NAT gateway, ginagamit ang landas ng private subnet. Pareho silang maaaring tama. Ang hindi mo maaaring tapusin ay ang browser sa server ay nagpapatunay ng forwarding para sa kliyente.

Huwag hayaang isang checkbox ang magsara ng imbestigasyon

Ang IPv6 ay hiwalay na desisyon. Ang patakaran ng buong tunnel para sa IPv4 ay walang sinasabi tungkol sa kung ang IPv6 ay dinadala, hinaharang o tumatagas, at ang dual-stack client ay maaaring magpatuloy na gumamit ng lokal na IPv6 path nito habang ang IPv4 ay nasa tunnel. Subukan ang address family na talagang mahalaga sa iyo, at tahasang magpasya kung dapat i-disable ang isa pa.

Panghuli, subukan ang disconnected state. Ang pagpili ng buong tunnel ay naglalarawan ng routing policy habang konektado, hindi kung ano ang nangyayari kapag bumagsak ang tunnel. Kung ang kinakailangan ay walang traffic na makatakas sa labas ng VPN, iyon ay tanong ng kill-switch at firewall, at kailangan nito ang sariling pagsubok sa halip na hinuha mula sa route table.