Pilns Access Server tunelis EC2: kāpēc ar vienu ķeksīti nepietiek

Avota un galamērķa pārbaudes izslēgšana EC2 instancē ir visbiežāk atkārtotā atbilde uz jautājumiem par Access Server interneta izeju, un viena pati tā jūsu klientiem neko nedara. Pārbaude ir AWS pāradresācijas ierobežojums: tā liek instancei pieņemt paketes, kuru avots vai galamērķis nav tās pašas adrese. Tā nepasaka Access Server klientam sūtīt interneta satiksmi pa tuneli, neveido ceļu uz augšu un nepievieno NAT. Mīts ir tāds, ka ķeksītis pats ir funkcija.

Ko pārbaude faktiski kontrolē

Katra EC2 tīkla saskarne izmet satiksmi, kas tai nav adresēta, ja vien instance nedarbojas kā maršrutētājs, NAT ierīce vai VPN vārteja un jūs šo pārbaudi neizslēdzat. Izslēgšana dod atļauju pāradresēt. Atļauja nav konfigurācija: instancei joprojām vajag maršrutu uz interneta vārteju vai NAT ierīci, VPC maršrutu tabulai joprojām vajag atbilstošo ierakstu, drošības grupām joprojām jāatļauj plūsma, un serverim joprojām jātulko vai jāmaršrutē atgaitas satiksme.

Pārbaudiet pašreizējo vērtību ar aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck pirms kaut ko maināt. Ja maināt to konsolē, mainiet tāpēc, ka instance pāradresē citu labā, nevis tāpēc, ka klients nevar sasniegt internetu.

Klienta maršrutēšanas politika pieder Access Server

Access Server 3 atveriet Access Controls un atrodiet sadaļu Internet Access and DNS. Internet Gateway izvēle piedāvā pilnu vai sadalītu tuneli; pilns tunelis liek klientam maršrutēt savu noklusējuma satiksmi VPN iekšienē, sadalītais atstāj interneta satiksmi klienta vietējā ceļā. Saglabājiet un lietojiet caur produkta darbplūsmu, pēc tam no jauna pievienojiet testa klientu, jo politika tiek piegādāta savienojuma brīdī.

Vecāki laidieni izmanto citas izvēlnes, un dažiem Community OpenVPN būvējumiem nav līdzvērtīgas vadības. Pārbaudiet instalēto galveno versiju pirms ekrāna meklēšanas, kura nav. Pēc tam apstipriniet, ko klients saņēma: pilna tuneļa profilam jāinstalē noklusējuma maršruts pa tuneli, un sadalītā tuneļa profilam tas nav jādara.

Izsekojiet pakei pēc tuneļa

Kad klients nosūta interneta satiksmi tunelī, serverim tā jāpāradresē un parasti jātulko. Access Server pārvalda savus NAT un maršrutēšanas noteikumus, tāpēc lasiet faktisko konfigurāciju, nevis pievienojiet Community OpenVPN noteikumus ģenerētajiem failiem; nepārvaldīti noteikumi tiek pārrakstīti vai nonāk konfliktā nākamajā produkta atjauninājumā. sudo iptables -t nat -L -n -v vai nftables ekvivalents parāda, kas patiešām tiek tulkots.

AWS puse ir atsevišķs ceļš. Instance publiskajā apakštīklā sasniedz interneta vārteju tieši un saglabā savu publisko adresi vai elastīgo IP. Instancei privātajā apakštīklā vajag maršrutu uz NAT vārteju vai NAT instanci, un NAT ierīcei vajag savu maršrutu uz interneta vārteju. Interneta vārtejas pievienošana VPC pati par sevi nedod nevienam privātam avotam publisku atgaitas adresi, tāpēc viena un tā pati Access Server konfigurācija darbojas vienā apakštīklā un klusi neizdodas citā.

Pārbaudiet maršrutu tabulu, kas saistīta ar instances apakštīklu, ne tikai VPC galveno tabulu. Apakštīklu asociācijas pārspēj galveno tabulu, un novecojusi asociācija ir biežs iemesls, kāpēc strādājoša konfigurācija apstājas pēc pārbūves.

Turiet IP izeju un DNS atsevišķi

Vispirms pārbaudiet adreses literāli, pēc tam vārdu, no tās pašas klienta lietotnes. Ja curl -4 https://checkip.amazonaws.com atgriež publisku adresi, bet resursdatoru nosaukumi neizdodas, tunelis un NAT ceļš strādā, un problēma ir DNS: nosūtītais atrisinātājs, klienta atrisinātāja stāvoklis vai drošības grupa, kas bloķē atrisinātāju. Access Server DNS iestatījumi atrodas tajā pašā Internet Access apgabalā, bet tie ceļo pa citu koda ceļu.

Salīdziniet atgriezto adresi ar paredzēto izeju. Ja tā ir instances publiskā adrese, satiksmi tulko instance; ja tā ir NAT vārtejas adrese, tiek izmantots privātā apakštīkla ceļš. Abi var būt pareizi. Ko jūs nevarat secināt, ir tas, ka pārlūkprogramma uz servera pierāda klienta pāradresāciju.

Neļaujiet vienam ķeksītim noslēgt izmeklēšanu

IPv6 ir atsevišķs lēmums. Pilna tuneļa politika IPv4 neko nepasaka par to, vai IPv6 tiek pārnests, bloķēts vai noplūst, un divu steku klients var turpināt izmantot savu vietējo IPv6 ceļu, kamēr IPv4 ir tunelī. Pārbaudiet adrešu saimi, kas jums patiešām svarīga, un skaidri izlemiet, vai otru vajadzētu atspējot.

Visbeidzot, pārbaudiet atvienoto stāvokli. Pilna tuneļa izvēle apraksta maršrutēšanas politiku savienojuma laikā, nevis to, kas notiek, kad tunelis nokrīt. Ja prasība ir, lai neviena satiksme neizplūstu ārpus VPN, tas ir kill-switch un ugunsmūra jautājums, un tam vajag savu testu, nevis secinājumu no maršrutu tabulas.