Teljes tunnel az Access Serveren EC2-n: miért nem elég egy jelölőnégyzet

A forrás- és célcím-ellenőrzés kikapcsolása egy EC2-példányon a leggyakrabban ismételt válasz az Access Server internetes kimenetével kapcsolatos kérdésekre, és önmagában semmit nem tesz az ügyfeleiért. Az ellenőrzés AWS továbbítási korlát: eléri, hogy a példány elfogadjon olyan csomagokat, amelyeknek a forrása vagy a célja nem a saját címe. Nem mondja meg az Access Server ügyfélnek, hogy az internetes forgalmat a tunnelen keresztül küldje, nem hoz létre felfelé vezető útvonalat, és nem ad hozzá NAT-ot. A mítosz az, hogy a jelölőnégyzet maga a funkció.

Mit szabályoz valójában az ellenőrzés

Minden EC2 hálózati interfész eldobja a nem hozzá címzett forgalmat, kivéve ha a példány útválasztóként, NAT-eszközként vagy VPN-átjáróként működik, és ön kikapcsolja ezt az ellenőrzést. A kikapcsolás engedélyt ad a továbbításra. Az engedély nem konfiguráció: a példánynak továbbra is kell útvonal egy internetátjáróhoz vagy NAT-eszközhöz, a VPC útvonaltáblájának továbbra is kell a megfelelő bejegyzés, a biztonsági csoportoknak továbbra is engedélyezniük kell a folyamot, és a kiszolgálónak továbbra is le kell fordítania vagy továbbítania a visszforgalmat.

Ellenőrizze a jelenlegi értéket a aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck segítségével, mielőtt bármit módosítana. Ha a konzolon módosítja, azért tegye, mert a példány mások helyett továbbít, nem azért, mert egy ügyfél nem éri el az internetet.

Az ügyfél útválasztási házirendje az Access Serveré

Az Access Server 3-ban nyissa meg az Access Controls elemet, és keresse meg az Internet Access and DNS szakaszt. Az Internet Gateway választó teljes vagy osztott tunnelt kínál; a teljes tunnel arra utasítja az ügyfelet, hogy az alapértelmezett forgalmát a VPN-be irányítsa, az osztott tunnel az ügyfél helyi útvonalán hagyja az internetes forgalmat. Mentse el és alkalmazza a termék munkafolyamatán keresztül, majd csatlakoztassa újra a tesztügyfelet, mert a házirend a kapcsolódás pillanatában kerül átadásra.

A régebbi kiadások más menüket használnak, és néhány Community OpenVPN buildnek nincs egyenértékű vezérlése. Ellenőrizze a telepített főverziót, mielőtt olyan képernyőt keresne, amely nem létezik. Ezután erősítse meg, mit kapott az ügyfél: a teljes tunnel profilnak alapértelmezett útvonalat kell telepítenie a tunnelen keresztül, az osztott tunnel profilnak pedig nem.

Kövesse a csomagot a tunnel után

Amint az ügyfél internetes forgalmat küld a tunnelbe, a kiszolgálónak továbbítania kell, és általában le is kell fordítania. Az Access Server a saját NAT- és útválasztási szabályait kezeli, ezért a tényleges konfigurációt olvassa, ahelyett hogy Community OpenVPN szabályokat fűzne a generált fájlokhoz; a nem kezelt szabályok felülíródnak vagy ütköznek a következő termékfrissítéskor. A sudo iptables -t nat -L -n -v vagy az nftables megfelelője megmutatja, mi fordul le valójában.

Az AWS oldal külön útvonal. Egy nyilvános alhálózatban lévő példány közvetlenül eléri az internetátjárót, és megtartja nyilvános címét vagy rugalmas IP-jét. Egy privát alhálózatban lévő példánynak útvonalra van szüksége egy NAT-átjáróhoz vagy NAT-példányhoz, a NAT-eszköznek pedig saját útvonalra az internetátjáróhoz. Az internetátjáró VPC-hez csatolása önmagában egyetlen privát forrásnak sem ad nyilvános visszacímét, ezért ugyanaz az Access Server beállítás működik az egyik alhálózatban, a másikban pedig csendben meghiúsul.

Ellenőrizze a példány alhálózatához társított útvonaltáblát, ne csak a VPC fő tábláját. Az alhálózati társítások felülírják a fő táblát, és az elavult társítás gyakori oka annak, hogy egy működő konfiguráció újraépítés után leáll.

Tartsa külön az IP-kimenetet és a DNS-t

Először egy címkonstanst, majd egy nevet teszteljen ugyanabból az ügyfélalkalmazásból. Ha a curl -4 https://checkip.amazonaws.com nyilvános címet ad vissza, de a gazdagépnevek meghiúsulnak, a tunnel és a NAT-útvonal működik, és a probléma a DNS: a kiküldött feloldó, az ügyfél feloldójának állapota, vagy egy biztonsági csoport, amely blokkolja a feloldót. Az Access Server DNS-beállításai ugyanabban az Internet Access területen vannak, de más kódútvonalon haladnak.

Hasonlítsa össze a visszakapott címet a szándékolt kimenettel. Ha ez a példány nyilvános címe, a forgalmat a példány fordítja le; ha NAT-átjáró címe, akkor a privát alhálózat útvonala van használatban. Mindkettő helyes lehet. Amit nem következtethet ki, az az, hogy a kiszolgálón lévő böngésző bizonyítja az ügyfél továbbítását.

Ne hagyja, hogy egy jelölőnégyzet lezárja a vizsgálatot

Az IPv6 külön döntés. Az IPv4 teljes tunnel házirendje semmit nem mond arról, hogy az IPv6 átvitelre kerül, blokkolva van vagy szivárog, és egy kettős veremű ügyfél továbbra is használhatja helyi IPv6 útvonalát, miközben az IPv4 a tunnelben van. Tesztelje azt a címcsaládot, amely valóban fontos önnek, és döntse el kifejezetten, hogy a másikat ki kell-e kapcsolni.

Végül tesztelje a bontott állapotot. A teljes tunnel kiválasztása a csatlakozott állapot útválasztási házirendjét írja le, nem azt, hogy mi történik a tunnel megszakadásakor. Ha a követelmény az, hogy semmilyen forgalom ne szökjön ki a VPN-en kívülre, az kill-switch és tűzfal kérdése, és saját tesztet igényel az útvonaltáblából levont következtetés helyett.