LAN aiz vienas AWS Client VPN sesijas: kas tiek pārsūtīts

Klēpjdators pieslēdzas AWS Client VPN galapunktam, sasniedz privāto apakštīklu, un viss izskatās veselīgi. Darbvirsma tajā pašā LAN neko nesasniedz, lai gan Linux resursdatoram arī ir tilta saskarne un abas mašīnas ir uz viena kabeļa. Tunelī nekas nav nepareizi konfigurēts; trūkstošā daļa ir maršrutēšana, un tilts ir maldinošas pēdas.

Client VPN sesijas paplašināšana uz LAN ir vārtejas loma. Tas nav Ethernet segments, kas izstiepts vadāmā pakalpojumā.

Resursdators strādā, bet LAN — ne

Linux mašīnas tuneļa saskarnei ir adrese Client VPN klienta CIDR iekšpusē, un galapunkts ir nosūtījis maršrutus VPC diapazoniem. Pieprasījums šajā mašīnā ir lokāli ģenerēta plūsma: tas izvēlas maršrutu, iziet caur tuneli un saņem atbildi. Šis ceļš nekad neskar pārsūtīšanas kodu, LAN saskarni vai kādu ugunsmūra noteikumu, kas pārvalda tranzītu.

Plūsma no citas LAN ierīces ir cita plūsma. Tā nonāk LAN saskarnē, tai vajag maršrutu, kas norāda uz tuneli, vajag iespējotu pārsūtīšanu, vajag ugunsmūri, kas to atļauj, un vajag, lai atbilde atgrieztos pa to pašu resursdatoru. Četras prasības, un strādājošais klēpjdatora tests nepierāda nevienu. No darbvirsmas bojājums izskatās dīvaini: tunelis ir uz augšu, akreditācijas dati ir derīgi, un galamērķis vienkārši nekad neatbild. Defekts ir lokāls vārtejas pārsūtīšanas ceļā, nevis pakalpojumā.

Ne katrs klients var būt vārteja

AWS norāda, ka tās Client VPN darbvirsmas lietotne neatbalsta IP pārsūtīšanu, un ka citi klienti var atbalstīt. Šis ierobežojums nosaka arhitektūru pirms jebkuras komandas ievadīšanas. Ja vienīgais pieejamais klients ir oficiālā darbvirsmas lietotne, Linux vārteja, kas pārsūta LAN, nav konfigurācija, ko varat pabeigt, un nekāds masquerading to nemainīs.

Aizstājējam klientam arī jāatbilst galapunkta autentifikācijas metodei un politikai, ko plānojat ieviest. Galapunkti, kuru pamatā ir sertifikāti, direktorijs un SAML, nepieņem tādas pašas klienta konfigurācijas, un trešās puses klients, kas autentificējas, bet ignorē nosūtītos maršrutus, nav uzlabojums.

Uzskatiet klienta izvēli par dizaina pārskatīšanas daļu. Tas nosaka, vai LAN pārsūtīšanas modelis vispār ir pieejams, un nosaka, kādu identitāti galapunkts redz katrai ierīcei aiz vārtejas. Pierakstiet klientu un galapunkta konfigurāciju, pret kuru tas tika testēts. Klienta nomaiņa pēc pusgada var klusi noņemt iespēju, ko dizains pieņēma.

Novirziet LAN uz tuneli un iztulkojiet to

Ar atbalstītu klientu vietā pārējais ir parasts vārtejas darbs. LAN ierīcēm vajag maršrutu VPC diapazonam, kas norāda uz Linux resursdatoru, un resursdatoram vajag iespējotu pārsūtīšanu. Ja vēlaties, lai VPC redzētu plūsmu kā pieslēgtu klientu, nevis kā patvaļīgu LAN adresi, iztulkojiet avotu izejā.

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

Ierobežojiet noteikumu ar tuneļa saskarni un VPC diapazonu, kā iepriekš, nevis maskējiet visu, ko resursdators pārsūta. Šaurāks noteikums ir vieglāk pārdomājams, un tas klusi nemaina plūsmu, kurai bija jāsaglabā sākotnējā avota adrese.

Ļaujiet LAN maršrutam parādīties automātiski, ja varat: DHCP opcija, maršrutētāja paziņojums vai statisks maršruts, ko nosūta tas, kas pārvalda LAN. Maršruts, kas pastāv tikai vienā testa mašīnā, liks dizainam izskatīties salauztam tajā brīdī, kad kāds cits to izmēģinās.

Arī atbildei vajag ceļu

Kad pieprasījums sasniedz VPC, atbildei jāatgriežas pa tiem pašiem tulkošanas stāvokļiem un jāatrod LAN maršruts vārtejā. Šī daļa parasti darbojas, kad masquerade noteikums ir vietā, jo kartējums dzīvo tajā resursdatorā, kas to veica. Tā lūst, ja VPC pusē ir maršruts, kas atbildi sūta citur, tāpēc svarīgs ir gan klienta CIDR maršruts, gan apakštīkla piesaiste galapunktā.

Vērojiet skaitītājus, ne tikai ping. Masquerade noteikums ar nulli paketēm stāsta, ka pieprasījums nekad nav sasniedzis tuneļa saskarni, kas norāda atpakaļ uz LAN maršrutu vai paša klienta maršrutēšanas tabulu. Noteikums ar paketēm, bet bez atbildēm, norāda uz VPC pusi, autorizācijas noteikumiem vai drošības grupu, kas nepieņem iztulkoto avotu. Pirms kaut ko mainīt, izlasiet abus virzienus, jo skaitlis, kas aug tikai vienā pusē, ir vienvirziena ceļš, nevis lēns.

Atcerieties, ka galapunkts ir pārvaldīts pakalpojums. Nav servera konfigurācijas faila, ko rediģēt, un nav client-config direktīvas, ko pievienot, tāpēc instrukcijas, kas rakstītas pašpārvaldītam OpenVPN serverim ar pielāgotiem klienta apakštīkla maršrutiem, netiek pārnestas. AWS sviras ir apakštīkla piesaiste, autorizācijas noteikumi un VPC maršrutēšanas tabulas.

Kopīgā identitāte ir daļa, uz kuru politikai jāatbild

Katra ierīce aiz vārtejas izmanto vārtejas VPN sesiju. Galapunkta autorizācijas noteikumi piešķir piekļuvi lietotājam vai grupai, un no pakalpojuma viedokļa šajā sesijā ir tieši viens lietotājs. Lokālā pārsūtīšana nereizina šo identitāti autentifikācijā katrai ierīcei, un tā nepaplašina ierīces stāvokļa pārbaudes līdz stūrī esošajam printerim.

Tas var būt pieņemami, vai arī tas var būt iemesls, kāpēc dizains tiek noraidīts. Tas ir atkarīgs no tā, ko VPC resursi pieņem par to, kas zvana. Kopīga identitāte, kas iederas autorizācijas modelī, ir labi; tā, kas klusi pārvērš vienu autentificētu sesiju piekļuvē visam LAN, ir atradums, kas gaida uzrakstīšanu.

Ja prasība patiešām ir savienot visu vietni ar VPC, salīdziniet atbalstītu vietnes-uz-vietni dizainu pirms attālinātās piekļuves klienta paplašināšanas. Semantika atšķiras, un NAT-ota klienta sesija ir vājš vietnes saites aizstājējs, kad VPC jāuzsāk savienojumi uz LAN.

Izlemiet klientu, maršrutu, tulkošanu un identitātes stāstu šajā secībā. Katrs ierobežo nākamo, un secība izskaidro, kāpēc resursdators strādā, bet LAN — ne.