Access Serverin täysi tunneli EC2:ssa: miksi yksi valintaruutu ei riitä

Lähde- ja kohdeosoitteen tarkistuksen poistaminen käytöstä EC2-instanssissa on toistetuin vastaus Access Serverin internet-ulostuloa koskeviin kysymyksiin, eikä se yksinään tee asiakkaillesi mitään. Tarkistus on AWS:n edelleenlähetysrajoitus: se saa instanssin hyväksymään paketteja, joiden lähde tai kohde ei ole sen oma osoite. Se ei kerro Access Server -asiakkaalle, että internet-liikenne pitää lähettää tunnelin kautta, se ei luo reittiä ylöspäin eikä lisää NAT:ia. Myytti on, että valintaruutu on se ominaisuus.

Mitä tarkistus todella ohjaa

Jokainen EC2-verkkoliittymä pudottaa liikenteen, jota ei ole osoitettu sille, ellei instanssi toimi reitittimenä, NAT-laitteena tai VPN-yhdyskäytävänä ja poista tarkistusta käytöstä. Käytöstä poistaminen antaa luvan edelleenlähetykseen. Lupa ei ole kokoonpano: instanssi tarvitsee edelleen reitin internet-yhdyskäytävään tai NAT-laitteeseen, VPC:n reititystaulu tarvitsee edelleen vastaavan merkinnän, tietoturvaryhmien on edelleen sallittava virtaus, ja palvelimen on edelleen käännettävä tai reititettävä paluuliikenne.

Tarkista nykyinen arvo komennolla aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck ennen kuin muutat mitään. Jos muutat sitä konsolissa, muuta siksi, että instanssi välittää muiden puolesta, ei siksi, ettei asiakas pääse internetiin.

Asiakkaan reitityskäytäntö kuuluu Access Serverille

Avaa Access Serverissä 3 Access Controls ja etsi Internet Access and DNS -osio. Internet Gateway -valinta tarjoaa täyden tai jaetun tunnelin; täysi tunneli käskee asiakasta reitittämään oletusliikenteensä VPN:ään, jaettu tunneli jättää internet-liikenteen asiakkaan paikalliselle reitille. Tallenna ja ota käyttöön tuotteen työnkulun kautta ja yhdistä sitten testiasiakas uudelleen, koska käytäntö toimitetaan yhteyden muodostamisen hetkellä.

Vanhemmat versiot käyttävät eri valikoita, eikä joissakin Community OpenVPN -koonnoksissa ole vastaavaa hallintaa. Tarkista asennettu pääversio ennen kuin etsit näyttöä, jota ei ole olemassa. Vahvista sitten, mitä asiakas sai: täyden tunnelin profiilin pitäisi asentaa oletusreitti tunnelin kautta, eikä jaetun tunnelin profiilin pitäisi tehdä niin.

Seuraa pakettia tunnelin jälkeen

Kun asiakas lähettää internet-liikenteen tunneliin, palvelimen on välitettävä se ja yleensä käännettävä se. Access Server hallinnoi omia NAT- ja reitityssääntöjään, joten lue voimassa oleva kokoonpano sen sijaan, että lisäisit Community OpenVPN -sääntöjä luotuihin tiedostoihin; hallitsemattomat säännöt korvataan tai ne törmäävät tuotteen seuraavassa päivityksessä. sudo iptables -t nat -L -n -v tai nftablesin vastine näyttää, mitä todella käännetään.

AWS:n puoli on erillinen reitti. Julkisen aliverkon instanssi saavuttaa internet-yhdyskäytävän suoraan ja säilyttää julkisen osoitteensa tai elastisen IP:n. Yksityisen aliverkon instanssi tarvitsee reitin NAT-yhdyskäytävään tai NAT-instanssiin, ja NAT-laite tarvitsee oman reittinsä internet-yhdyskäytävään. Internet-yhdyskäytävän liittäminen VPC:hen ei itsessään anna millekään yksityiselle lähteelle julkista paluuosoitetta, minkä vuoksi sama Access Server -kokoonpano toimii yhdessä aliverkossa ja epäonnistuu hiljaisesti toisessa.

Tarkista instanssin aliverkkoon liitetty reititystaulu, ei vain VPC:n päätaulua. Aliverkkoliitokset ohittavat päätaulun, ja vanhentunut liitos on yleinen syy sille, että toimiva kokoonpano pysähtyy uudelleenrakennuksen jälkeen.

Pidä IP-ulostulo ja DNS erillään

Testaa ensin osoiteliteraali ja sitten nimi samasta asiakassovelluksesta. Jos curl -4 https://checkip.amazonaws.com palauttaa julkisen osoitteen mutta isäntänimet epäonnistuvat, tunneli ja NAT-reitti toimivat ja ongelma on DNS:ssä: työnnetty resolver, asiakkaan resolverin tila tai tietoturvaryhmä, joka estää resolverin. Access Serverin DNS-asetukset ovat samalla Internet Access -alueella, mutta ne kulkevat eri koodipolkua.

Vertaa palautettua osoitetta aiottuun ulostuloon. Jos se on instanssin julkinen osoite, instanssi kääntää liikenteen; jos se on NAT-yhdyskäytävän osoite, käytössä on yksityisen aliverkon reitti. Kumpikin voi olla oikein. Sitä et voi päätellä, että palvelimella oleva selain todistaisi asiakkaan edelleenlähetyksen.

Älä anna yhden valintaruudun sulkea tutkintaa

IPv6 on erillinen päätös. IPv4:n täyden tunnelin käytäntö ei kerro mitään siitä, kuljetetaanko IPv6:ta, estetäänkö se vai vuotaako se, ja kaksoispino-asiakas voi jatkaa paikallisen IPv6-reittinsä käyttöä, kun IPv4 on tunnelissa. Testaa osoiteperhe, jolla todella on sinulle merkitystä, ja päätä nimenomaisesti, pitäisikö toinen poistaa käytöstä.

Testaa lopuksi irrotettu tila. Täyden tunnelin valinta kuvaa reitityskäytäntöä yhteyden aikana, ei sitä, mitä tapahtuu tunnelin pudotessa. Jos vaatimus on, ettei mikään liikenne karkaa VPN:n ulkopuolelle, se on kill-switch- ja palomuurikysymys, ja se vaatii oman testinsä eikä päätelmää reititystaulusta.