LAN bak við eina AWS Client VPN lotu: hvað er flutt áfram

Fartölvan tengist AWS Client VPN endapunktinum, nær einkareitnum og allt lítur heilbrigt út. Skjáborðið á sama LAN-i nær hvergi, þótt Linux hýsillinn hafi líka brúartengi og báðar vélarnar séu á sama kapli. Ekkert er rangt stillt í göngunum; hluti sem vantar er leiðarval, og brúin er rangur vegvísir.

Að útvíkka Client VPN lotu út á LAN er hlutverk gáttar. Það er ekki Ethernet hluti sem er teygður inn í stýrða þjónustu.

Hýsillinn virkar og LAN-ið ekki

Göngutengið á Linux vélinni hefur vistfang innan CIDR biðlara Client VPN, og endapunkturinn hefur ýtt leiðum fyrir VPC sviðin. Beiðni sem er gerð á þeirri vél er staðbundið mynduð umferð: hún velur leið, fer út um göngin og fær svar. Þessi leið snertir aldrei áframflutningskóðann, LAN tengið né neina eldveggsreglu sem stjórnar gegnumferð.

Umferð frá öðru LAN tæki er önnur flæði. Hún berst á LAN tengið, þarf leið sem bendir inn í göngin, þarf virkan áframflutning, þarf eldvegg sem leyfir hana og þarf að svarið komi til baka um sama hýsil. Fjögur skilyrði, og virka fartölvuprófið sannar ekkert þeirra. Frá skjáborðinu virðist bilunin undarleg: göngin eru uppi, skírteinin gild og áfangastaðurinn svarar einfaldlega aldrei. Gallinn er staðbundinn í áframflutningsleið gáttarinnar, ekki í þjónustunni.

Ekki getur hver biðlari verið gátt

AWS segir að skjáborðsforrit þess fyrir Client VPN styðji ekki IP áframflutning, og að aðrir biðlarar kunni að gera það. Þessi takmörkun ræður arkitektúrnum áður en nokkur skipun er slegin inn. Ef eini biðlarinn sem er tiltækur er hið opinbera skjáborðsforrit, er Linux gátt sem flytur áfram fyrir LAN-ið ekki uppsetning sem þú getur klárað, og engin masquerading mun breyta því.

Staðgengilbiðlarinn verður líka að passa við auðkenningaraðferð endapunktsins og þá stefnu sem þú hyggst framfylgja. Endapunktar sem byggja á skírteinum, skrá og SAML taka ekki við sömu biðlarastillingum, og þriðja aðila biðlari sem auðkennir sig en hunsar ýttu leiðirnar er ekki bóta.

Meðhöndlaðu biðlaravalið sem hluta af hönnunarýfrferð. Það ákvarðar hvort LAN áframflutningsmynstrið sé yfirhöfuð tiltækt, og það ákvarðar hvaða sjálfsmynd endapunkturinn sér fyrir hvert tæki bak við gáttina. Skráðu biðlarann og endapunktastillinguna sem prófað var gegn. Skipti á biðlara hálfu ári síðar getur hljóðlega fjarlægt getuna sem hönnunin gerði ráð fyrir.

Beindu LAN-inu í göngin og þýddu það

Með studdan biðlara á sínum stað er restin venjuleg gáttavinna. LAN tækin þurfa leið fyrir VPC sviðið sem bendir á Linux hýsilinn, og hýsillinn þarf virkan áframflutning. Ef þú vilt að VPC-ið sjái umferðina sem tengda biðlarann frekar en sem handahófskennt LAN vistfang, þýddu upprunann á leið út.

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

Takmarkaðu regluna við göngutengið og VPC sviðið, eins og hér að ofan, í stað þess að masquerade allt sem hýsillinn flytur áfram. Þrengri reglan er auðveldari í rökstuðningi, og hún breytir ekki hljóðlega umferð sem átti að halda upprunalegu upprunavistfangi sínu.

Láttu LAN leiðina koma sjálfkrafa ef þú getur: DHCP valkostur, tilkynning frá beini eða stök leið sem ýtt er af því sem stýrir LAN-inu. Leið sem er aðeins til á einni prófvél mun láta hönnunina líta út fyrir að vera brotna á því augnabliki sem einhver annar prófar hana.

Svarið þarf líka leið

Þegar beiðnin nær VPC-inu verður svarið að koma til baka um sömu þýðingarstöður og finna LAN leiðina á gáttinni. Sá hluti virkar venjulega þegar masquerade reglan er til staðar, því vörpunin lifir á hýslinum sem framkvæmdi hana. Hann brestur þegar VPC hliðin er með leið sem sendir svarið annað, og þess vegna skipta bæði CIDR leið biðlarans og tenging undirnets á endapunktinum máli.

Fylgstu með teljurunum, ekki bara pinginu. Masquerade regla með núll pakka segir þér að beiðnin hafi aldrei náð göngutenginu, sem bendir til baka á LAN leiðina eða eigin leiðarvísistöflu biðlarans. Regla með pakka en engin svör bendir á VPC hliðina, heimildarreglurnar eða öryggishóp sem tekur ekki við þýdda upprunanum. Lestu báðar áttir áður en þú breytir nokkru, því talning sem vex aðeins á annarri hlið er einstefnuleið en ekki hæg leið.

Mundu að endapunkturinn er stýrð þjónusta. Það er engin netþjónsstillingarskrá til að breyta og engin client-config tilskipun til að bæta við, svo leiðbeiningar sem skrifaðar eru fyrir sjálfstýrðan OpenVPN netþjón með sérsniðnum undirnetsleiðum biðlara flytjast ekki yfir. Á AWS eru stýrin undirnetstenging, heimildarreglur og leiðarvísistöflur VPC-sins.

Sameiginleg sjálfsmynd er sá hluti sem stefnan verður að svara

Hvert tæki bak við gáttina notar VPN lotu gáttarinnar. Heimildarreglur endapunktsins veita notanda eða hóp aðgang, og frá sjónarhorni þjónustunnar er nákvæmlega einn notandi í þeirri lotu. Staðbundinn áframflutningur margfaldar ekki þá sjálfsmynd í auðkenningu fyrir hvert tæki, og hann útvíkkar ekki stöðuprófanir tækja út í prentarann í horninu.

Það kann að vera ásættanlegt, eða það kann að vera ástæðan fyrir því að hönnuninni er hafnað. Það fer eftir því hvað VPC auðlindirnar gera ráð fyrir um hver hringir. Sameiginleg sjálfsmynd sem passar við heimildarlíkanið er í lagi; sú sem breytir hljóðlega einni auðkenndri lotu í aðgang að öllu LAN-inu er niðurstaða sem bíður þess að vera skrifuð.

Ef krafan er í raun að tengja heilt svæði við VPC, berðu saman studda svæði-til-svæðis hönnun áður en þú útvíkkar fjartengingu biðlara. Merkingin er önnur, og NAT-uð biðlaralota er léleg staðgengil fyrir svæðistengingu þegar VPC-ið þarf að hefja tengingar inn á LAN-ið.

Ákveddu biðlarann, leiðina, þýðinguna og sjálfsmyndarsöguna í þeirri röð. Hver takmarkar þá næstu, og röðin útskýrir hvers vegna hýsillinn virkar á meðan LAN-ið gerir það ekki.