EC2 Elastic IP nav instances privātā VPN adrese
Viesis nekad neredz Elastic IP. Izsekojiet, kur notiek tulkošana, pēc tam izvēlieties adresi, kas pieder ceļam, kas jums patiešām nepieciešams.
Instancei ir privāta adrese, Elastic IP ir ar to saistīta, un maršruts šim publiskajam /32 tiek pievienots VPN cerībā, ka abi kļūs par vienu un to pašu. Nekļūst. Elastic IP ir tulkojums, kas tiek veikts ārpus viesa, interneta vārtejā, trafikā, kas iet interneta ceļu. Viesa operētājsistēma nekad neredz šo adresi konfigurētu saskarnē. Tās pievienošana tuneļa saskarnei neatkārto augšupējo tulkojumu un rada otru, pretrunīgu identitāti tai pašai mašīnai.
Divas adreses, viena instance
Instances tīkla saskarnei ir privāta adrese VPC iekšienē, un tā ir adrese, ko viesis zina. Elastic IP ir saistīta ar to pašu saskarni, bet dzīvo kartējuma publiskajā pusē.
Viss, kas sasniedz instanci pa internetu, ierodas pārtulkots uz privāto adresi. Viss, ko instance sūta uz internetu, iziet ar Elastic IP kā avotu, atkal šī tulkojuma dēļ.
Viesa iekšienē pastāv viena adrese. Ārpusē — divas. Šī asimetrija izskaidro lielāko daļu neskaidrības šajā jomā. Viesis nevar konfigurēt to, ko vārteja pārtulko. Tas var atbildēt tikai uz adresi, kas tam patiešām ir.
Ko interneta vārteja patiešām dara
AWS interneta vārtejas dokumentācija apraksta izkārtojumu: instance zina savu privāto IPv4 adresi, un vārteja nodrošina atbilstošo publiskā IPv4 vai Elastic IP tulkojumu trafikam interneta ceļā.
Tas ir tīkla adrešu tulkojums, nevis aizstājvārds. Kartējumu uztur vārteja, tas ir saistīts ar asociāciju un attiecas tikai uz pakešu datiem, kas to šķērso. Noņemiet asociāciju, un publiskā identitāte pazūd, viesim neko nepamanot.
Tāpēc privāta VPN pakete, kas adresēta publiskajam /32, netiek interpretēta no jauna kā privāta pakete uz viesa lokālo adresi. Pakete seko maršrutam, kam tā atbilst, un tas to nosūta uz interneta vārteju, un vārtejas uzvedība ir atkarīga no tā, vai ceļš ir atļauts abos virzienos.
Kāpēc tuneļa saskarnes triks neizdodas
Elastic IP piešķiršana tuneļa saskarnei prasa no viesa publisko adresi uzskatīt par lokālu. Tagad divas lietas pretendē uz to pašu adresi: vārtejas tulkojums interneta ceļā un lokālā saskarne tuneļa iekšienē. Atgriezeniskajam trafikam nav konsekventas atbildes, kura no tām ir spēkā.
Pat ja šķiet, ka tas strādā, dizains ir paslēpis īsto jautājumu. Klienti vai nu sasniedz privāto adresi pa tuneli, vai arī sasniedz publisko galapunktu pa internetu, un šiem diviem ceļiem ir atšķirīgas drošības grupas, atšķirīga reģistrēšana un atšķirīgi atteices režīmi.
Adrese nekad nebija problēma. Ceļa izvēle bija.
Trīs mērķi, trīs dizaini
Ja mērķis ir publisks VPN galapunkts, Elastic IP ir pareizais rīks: attālie vienaudži tam pievienojas pa internetu, un šifrētais transports beidzas instancē. Pēc tam iekšējais lietojumprogrammas trafiks izmanto privāto adresi.
Ja mērķis ir privāta piekļuve lietojumprogrammai, galamērķis ir privātā adrese vai privāts DNS nosaukums, kas tajā atrisinās, un VPN maršrutam, drošības grupai un atgriešanās ceļam visiem jāsakrīt. Elastic IP šajā dizainā vispār neparādās.
Ja mērķis ir stabila publiska izejas identitāte VPN lietotājiem, tas ir NAT dizains izejas pusē, nevis adrese klienta tunelī. Trīs līdzīgi skanoši mērķi dod trīs atšķirīgas diagrammas, un tikai viens no tiem ietver Elastic IP novietošanu jaunā vietā.
Pārbaudiet izvēlēto ceļu
Privātai piekļuvei pārliecinieties, ka VPN maršruts aptver privāto prefiksu, ka VPC maršrutu tabula atgriež trafiku tunelī, ka drošības grupa atļauj klienta avotu un ka paša klienta ugunsmūris atļauj atbildi. Pēc tam pārbaudiet vienu reālu pieprasījumu, nevis ping.
Publiskai piekļuvei pārliecinieties par klienta interneta izeju, publiskās ieejas maršrutēšanu un tās drošības politiku. Vai VPN klients var sasniegt publisko galapunktu pa tuneli, ir atkarīgs no tuneļa izejas un ugunsmūra noteikumiem, nevis no Elastic IP asociācijas.
Ja publiskam resursdatora nosaukumam jādarbojas no abām pusēm, izmantojiet DNS dizainu, kas atbild ar privāto adresi VPN klientiem un ar publisko adresi visiem pārējiem, un uzturiet sertifikātu derīgu nosaukumam, nevis adresei. Darba kārtība: nosauciet mērķi, izvēlieties tam piederošo adresi, pēc tam pārbaudiet maršrutus, politiku un vienu pieprasījumu.