A laptop csatlakozik az AWS Client VPN végponthoz, eléri a privát alhálózatot, és minden egészségesnek tűnik. Az ugyanazon a LAN-on lévő asztali gép semmit sem ér el, pedig a Linux hostnak is van hídinterfésze, és mindkét gép ugyanazon a kábelen van. Az alagútban semmi sincs rosszul konfigurálva; a hiányzó darab az útválasztás, a híd pedig zsákutca.

Egy Client VPN-munkamenet LAN-ra való kiterjesztése átjárószerep. Ez nem egy felügyelt szolgáltatásba nyújtott Ethernet-szegmens.

A host működik, a LAN nem

A Linux gép alagút-interfészének címe a Client VPN kliens CIDR-en belül van, és a végpont útvonalakat küldött a VPC-tartományokhoz. Az ezen a gépen indított kérés helyben előállított forgalom: útvonalat választ, kilép az alagúton, és választ kap. Ez az út soha nem érinti a továbbítási kódot, a LAN-interfészt vagy a tranzitot szabályozó tűzfalszabályt.

Egy másik LAN-eszközről érkező forgalom más folyam. A LAN-interfészen érkezik, kell neki egy az alagútba mutató útvonal, kell az engedélyezett továbbítás, kell egy tűzfal, amely engedi, és kell, hogy a válasz ugyanazon a hoston keresztül jöjjön vissza. Négy követelmény, és a működő laptopos teszt egyiket sem bizonyítja. Az asztali gépről a hiba furcsának tűnik: az alagút él, a hitelesítő adatok érvényesek, és a cél egyszerűen soha nem válaszol. A hiba az átjáró továbbítási útjában lokalizált, nem a szolgáltatásban.

Nem minden kliens lehet átjáró

Az AWS közli, hogy asztali Client VPN-alkalmazása nem támogatja az IP-továbbítást, más kliensek viszont igen. Ez a korlátozás még bármely parancs begépelése előtt eldönti az architektúrát. Ha az egyetlen elérhető kliens a hivatalos asztali alkalmazás, a LAN-ért továbbító Linux-átjáró nem olyan konfiguráció, amelyet be lehet fejezni, és semmilyen masquerading nem változtat ezen.

A cserekliensnek meg kell felelnie a végpont hitelesítési módszerének és az érvényesíteni kívánt szabályzatnak is. A tanúsítványalapú, címtáralapú és SAML-alapú végpontok nem fogadják el ugyanazokat a klienskonfigurációkat, és a harmadik féltől származó kliens, amely hitelesít, de figyelmen kívül hagyja a küldött útvonalakat, nem jelent javulást.

Tekintse a kliensválasztást a tervezési felülvizsgálat részének. Eldönti, hogy a LAN-továbbítási minta egyáltalán elérhető-e, és eldönti, hogy a végpont milyen identitást lát az átjáró mögötti minden eszköznél. Rögzítse a klienst és azt a végpontkonfigurációt, amellyel tesztelték. Egy fél évvel későbbi klienscsere csendben eltávolíthatja a tervezés által feltételezett képességet.

Irányítsa a LAN-t az alagútba, és fordítsa le

Támogatott klienssel a helyén a többi közönséges átjárómunka. A LAN-eszközöknek a VPC-tartományra mutató útvonal kell a Linux host felé, a hostnak pedig engedélyezett továbbítás. Ha azt szeretné, hogy a VPC a kapcsolódott kliensként lássa a forgalmat, és ne önkényes LAN-címként, fordítsa le a forrást kilépéskor.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Szűkítse a szabályt az alagút-interfészre és a VPC-tartományra, ahogy fent, ahelyett hogy mindent masquerade-elne, amit a host továbbít. A szűkebb szabály könnyebben átgondolható, és nem változtatja meg csendben azt a forgalmat, amelynek meg kellett tartania eredeti forráscímét.

Ha lehet, hagyja, hogy a LAN-útvonal automatikusan megérkezzen: DHCP-opció, útválasztó-hirdetés vagy statikus útvonal, amelyet a LAN-t kezelő eszköz küld. Az az útvonal, amely csak egyetlen tesztgépen létezik, abban a pillanatban töröttnek mutatja a tervezést, amikor valaki más kipróbálja.

A válasznak is kell út

Miután a kérés eléri a VPC-t, a válasznak ugyanazokon a fordítási állapotokon keresztül kell visszajönnie, és meg kell találnia a LAN-útvonalat az átjárón. Ez a rész általában működik, ha a masquerade-szabály a helyén van, mert a leképezés azon a hoston él, amely elvégezte. Akkor törik el, ha a VPC oldalán van egy útvonal, amely máshová küldi a választ; ezért számít a kliens CIDR-útvonala és a végpont alhálózat-hozzárendelése is.

Nézze a számlálókat, ne csak a pinget. A nulla csomagos masquerade-szabály azt mondja, hogy a kérés soha nem érte el az alagút-interfészt, ami visszautal a LAN-útvonalra vagy a kliens saját útválasztási táblájára. A csomagokkal rendelkező, de válasz nélküli szabály a VPC oldalára, az engedélyezési szabályokra vagy egy biztonsági csoportra mutat, amely nem fogadja el a lefordított forrást. Mindkét irányt olvassa el, mielőtt bármit változtat, mert az egyoldalúan növekvő szám egyirányú út, nem lassú.

Ne feledje, hogy a végpont felügyelt szolgáltatás. Nincs szerverkonfigurációs fájl, amelyet szerkeszteni lehetne, és nincs client-config direktíva, amelyet hozzá lehetne adni, ezért az egyéni kliens-alhálózati útvonalakkal rendelkező, önállóan felügyelt OpenVPN-kiszolgálóhoz írt utasítások nem vihetők át. Az AWS-en a karok az alhálózat-hozzárendelés, az engedélyezési szabályok és a VPC útválasztási táblái.

A megosztott identitás az a rész, amelyre a szabályzatnak válaszolnia kell

Az átjáró mögötti minden eszköz az átjáró VPN-munkamenetét használja. A végpont engedélyezési szabályai egy felhasználónak vagy csoportnak adnak hozzáférést, és a szolgáltatás szempontjából pontosan egy felhasználó van ebben a munkamenetben. A helyi továbbítás nem sokszorozza ezt az identitást eszközönkénti hitelesítéssé, és nem terjeszti ki az eszközpostúra-ellenőrzéseket a sarokban lévő nyomtatóra.

Ez elfogadható lehet, vagy éppen ez lehet az oka a tervezés elutasításának. Attól függ, hogy a VPC-erőforrások mit feltételeznek arról, ki hív. A megosztott identitás, amely illeszkedik az engedélyezési modellhez, rendben van; az, amely csendben egyetlen hitelesített munkamenetet LAN-szintű hozzáféréssé alakít, egy megállapítás, amely leírásra vár.

Ha a követelmény valóban egy egész telephely VPC-hez csatlakoztatása, hasonlítson össze egy támogatott telephely-telephely kialakítást, mielőtt kiterjesztene egy távoli hozzáférésű klienst. A szemantika eltér, és a NAT-olt kliensmunkamenet rossz helyettesítője a telephely-összeköttetésnek, amikor a VPC-nek kapcsolatokat kell kezdeményeznie a LAN felé.

Döntse el a klienst, az útvonalat, a fordítást és az identitástörténetet ebben a sorrendben. Mindegyik korlátozza a következőt, és a sorrend megmagyarázza, miért működik a host, miközben a LAN nem.

Kapcsolódó cikkek