Access Serveri täistunnel EC2-s: miks ühest märkeruudust ei piisa

Lähte- ja sihtkoha kontrolli väljalülitamine EC2 eksemplaris on kõige korduvam vastus Access Serveri internetiväljundi küsimustele ja üksi ei tee see teie klientide jaoks midagi. Kontroll on AWS-i edastamispiirang: see paneb eksemplari vastu võtma pakette, mille lähte- või sihtkoht ei ole tema enda aadress. See ei ütle Access Serveri kliendile, et saata internetiliiklus tunnelisse, ei loo ülesvoolu marsruuti ega lisa NAT-i. Müüt on see, et märkeruut ongi funktsioon.

Mida kontroll tegelikult juhib

Iga EC2 võrguliides viskab kõrvale liikluse, mis ei ole talle adresseeritud, välja arvatud juhul, kui eksemplar töötab ruuterina, NAT-seadmena või VPN-lüüsina ja te selle kontrolli välja lülitate. Väljalülitamine annab edastamisloa. Luba ei ole konfiguratsioon: eksemplar vajab endiselt marsruuti internetilüüsile või NAT-seadmele, VPC marsruutitabel vajab endiselt vastavat kirjet, turvagrupid peavad endiselt voolu lubama ja server peab endiselt tagasiliiklust tõlkima või marsruutima.

Kontrollige praegust väärtust käsuga aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck enne millegi muutmist. Kui muudate seda konsoolis, muutke seepärast, et eksemplar edastab teiste eest, mitte seepärast, et klient ei pääse internetti.

Kliendi marsruutimispoliitika kuulub Access Serverile

Avage Access Serveris 3 jaotis Access Controls ja leidke ala Internet Access and DNS. Valik Internet Gateway pakub täistunnelit või jaotatud tunnelit; täistunnel ütleb kliendile, et suunata oma vaikeliiklus VPN-i, jaotatud tunnel jätab internetiliikluse kliendi kohalikule teele. Salvestage ja rakendage toote töövoo kaudu, seejärel ühendage testklient uuesti, sest poliitika toimetatakse kohale ühenduse hetkel.

Vanemad väljaanded kasutavad teistsuguseid menüüsid ja mõnel Community OpenVPN buildil puudub samaväärne juhtelement. Kontrollige paigaldatud põhiversiooni enne, kui otsite ekraani, mida ei ole olemas. Seejärel kinnitage, mida klient sai: täistunneli profiil peaks paigaldama tunnelisse vaikimisi marsruudi ja jaotatud tunneli profiil ei peaks seda tegema.

Jälgige paketti pärast tunnelit

Kui klient on internetiliikluse tunnelisse saatnud, peab server selle edastama ja tavaliselt tõlkima. Access Server haldab oma NAT- ja marsruutimisreegleid, seega lugege kehtivat konfiguratsiooni, mitte ärge lisage Community OpenVPN-i reegleid genereeritud failidesse; haldamata reeglid kirjutatakse toote järgmisel uuendusel üle või lähevad vastuollu. sudo iptables -t nat -L -n -v või nftables-i vaste näitab, mida tegelikult tõlgitakse.

AWS-i pool on eraldi tee. Avaliku alamvõrgu eksemplar jõuab internetilüüsini otse ja säilitab oma avaliku aadressi või elastse IP. Privaatse alamvõrgu eksemplar vajab marsruuti NAT-lüüsile või NAT-eksemplarile ning NAT-seade vajab oma marsruuti internetilüüsile. Internetilüüsi kinnitamine VPC-le ei anna iseenesest ühelegi privaatsele allikale avalikku tagasiaadressi, mistõttu sama Access Serveri seadistus töötab ühes alamvõrgus ja ebaõnnestub vaikselt teises.

Kontrollige eksemplari alamvõrguga seotud marsruutitabelit, mitte ainult VPC peamist tabelit. Alamvõrkude seosed kaaluvad peamise tabeli üles ja aegunud seos on tavaline põhjus, miks töötav konfiguratsioon pärast ümberehitust seiskub.

Hoidke IP-väljund ja DNS lahus

Katsetage esmalt aadressi literaali, seejärel nime, samast kliendirakendusest. Kui curl -4 https://checkip.amazonaws.com tagastab avaliku aadressi, kuid hostinimed ebaõnnestuvad, töötavad tunnel ja NAT-tee ning probleem on DNS-is: saadetud resolver, kliendi resolveri olek või turvagrupp, mis resolverit blokeerib. Access Serveri DNS-i seaded asuvad samas Internet Access piirkonnas, kuid liiguvad teist kooditeed.

Võrrelge tagastatud aadressi väljumiga, mida kavatsesite. Kui see on eksemplari avalik aadress, tõlgib liiklust eksemplar; kui see on NAT-lüüsi aadress, kasutatakse privaatse alamvõrgu teed. Mõlemad võivad olla õiged. Mida te ei saa järeldada, on see, et serveris olev brauser tõestab kliendi edastamist.

Ärge laske ühel märkeruudul uurimist sulgeda

IPv6 on eraldi otsus. IPv4 täistunneli poliitika ei ütle midagi selle kohta, kas IPv6 kantakse, blokeeritakse või lekib, ja kahe virna klient võib jätkata oma kohaliku IPv6 tee kasutamist, kui IPv4 on tunnelis. Katsetage aadressiperekonda, mis teile tegelikult korda läheb, ja otsustage selgesõnaliselt, kas teine tuleks välja lülitada.

Lõpuks katsetage lahtiühendatud olekut. Täistunneli valik kirjeldab marsruutimispoliitikat ühendatud olekus, mitte seda, mis juhtub tunneli kukkudes. Kui nõue on, et ükski liiklus ei pääseks VPN-ist välja, on see kill-switchi ja tulemüüri küsimus ning see vajab oma katset, mitte järeldust marsruutitabelist.