Sarbide tartekakoa AWS Client VPN-rekin: aztertu lotutako azpisare bakoitza
AWS Client VPN saio batzuek aplikazioaren VPC-ra iristen dira, beste batzuek denbora-muga jasaten duten bitartean. Alderatu lehenik amaierako puntuaren ibilbideak lotura bakoitzaren VPC ibilbide-taularekin.
Erabiltzaile batek konektatzen du, barneko aplikazioa ireki eta erantzuna jasotzen du; amaierako puntu berean dagoen lankide batek denbora-muga jasotzen du Wi-Fi berean dagoen ordenagailu eramangarri beretik. Eredu hori client VPN amaierako puntuaren sinadura da, lotutako azpisare bat baino gehiago dituena eta non bideak ez diren baliokideak. Hau kontsolatik kanpora doa, bi fitxak erabakitzen baitute gainerako ikerketak merezi duen. Bezeroaren konfigurazioan ezerk ez du hori azaltzen.
Hasi amaierako puntuan eta zerrendatu loturak
VPC kontsoletik, ireki Client VPN endpoints, aukeratu amaierako puntua eta irakurri Associations fitxa. Lotura bakoitza erabilgarritasun-zona bateko azpisare bat da, eta bezeroa zerbitzuak konexioa eraikitzean aukeratzen duen azpisarean lurreratzen da. Idatzi azpisareen IDak eta bakoitzak benetan erabiltzen duen ibilbide-taula, bi zerrenda horiek baitira egin beharreko alderaketa.
Amaierako puntuak lotura bakarra erakusten badu, teoria okerra da eta bezeroa da susmagarri hobea.
Alderatu amaierako puntuaren ibilbide-taula lotura bakoitzarekin
Ireki Route table fitxa amaierako puntu berean. Hango helmuga-CIDR bakoitzak helburu bat du, eta client VPN batean helburua lotura da, ez ate. AWSek helmuga-sarrera eskatzen du lotutako azpisare bakoitzeko, beraz, horietako bat soilik helburatzen duen ibilbide batek sarbidea saioa non lurreratu den mendeko egiten du. Egia esan axola zaizun helmuga egiaztatu, eta gero bere baimen-araua, ibilbideak bidea ematen baitu eta arauak erabakitzen baitu nork erabil dezakeen.
Bi geruzak taulatzean, hutsa zaila da ez ikusten.
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
Bigarren errenkada da tiket gehienetan akats osoa. Amaierako puntuaren ibilbidea han dago, beraz inork ez du harago begiratzen, eta paketea jauzi bat geroago hiltzen da VPC barruan.
Jarraitu azpisare bakoitza bere ibilbide-taula eraginkorrera
Ibilbide-taularekiko lotura espliziturik ez duen azpisare batek VPCren taula nagusia heredatzen du. Irakurri benetan indarrean dagoen taula, izena zuzena dirudien hori ez, eta alderatu helmuga eta helburua, errenkadako etiketa ez.
AWSen sarbide tartekatuaren gida horrek loturen arteko ibilbide-estaldura gisa planteatzen du, eta hori da eredu zuzena. Amaierako puntuak paketea azpisare batera eramaten du, eta azpisare horren taulak oraindik jakin behar du non bizi den aplikazioaren sarea.
Konpondu falta den errenkada hura duen taulan. Lanean ari den azpisare batetik ibilbide-taula osoa kopiatzeak internet, gailu eta isolamendu erabakiak ere kopiatzen ditu, inoiz honetarako pentsatuak izan ez zirenak, eta truke hori hasi zinen etendura baino okerragoa izaten da.
Egiaztatu baimen-arauak, gero itzulera-bidea
Baimen-arauak helmugakoak eta taldekoak dira, eta ibilbideetatik bereiz ebaluatzen dira. Nonahi ibilbideak dituen baina erabiltzailearen taldearentzat araurik ez duen helmuga zulo beltz gisa jokatzen du, ibilbide-taula osasuntsua dirudiela.
Itzulera-bideak arreta bera merezi du. Peering konexio batek aplikazioaren VPCn bezeroaren CIDRra itzultzen duen ibilbidea behar du, bi muturretan trafikoa uzten duten segurtasun-taldeen arauak eta hura ez botatzen duten sare-ACLak. Norabide bakarreko irisgarritasuna, pingek funtzionatzen duenean eta TCP esku-emateak ez, normalean ACL edo segurtasun-talde bati seinalatzen dio, ez VPNari.
Amaierako puntuaren segurtasun-taldeak loturaren sare-interfaze elastikoetan daude, beraz, bezeroaren CIDRretik aplikazioaren portua uzten duen araua loturari atxiki behar zaio, ez instantziari soilik.
Egiaztatu berriz konektatuz, ez zorte oneko eskaera batekin
Split tunnelarekin, amaierako puntuaren ibilbideak konexioa ezartzean bidaltzen dira, beraz, aldatu den ibilbide-multzoak ez du inoiz konektatuta geratzen den bezero bat lortzen. Deskonektatu eta berriz konektatu onartutako bezeroaren bidez, eta gero egiaztatu ibilbide berriak makinan daudela.
Azkenik, erlazionatu konexio-erregistroa bezeroak jaso zuen helbidearekin, eta errepikatu proba behar beste aldiz lotura bat baino gehiago harrapatzeko. Konponketa baten ondorengo eskaera arrakastatsu bakarrak bide bat funtzionatzen duela frogatzen du, eta tiketak besteaz ziharduen.