Waarom EC2 nie jou AWS Client VPN-skootrekenaar kan bereik nie
Client VPN vertaal IPv4-kliëntbronne na die eindpunt se netwerkkoppelvlak. Daarom werk die antwoord, maar 'n nuwe verbinding vanaf EC2 nie.
'n Skootrekenaar wat deur AWS Client VPN verbind is, bereik 'n EC2-toepassing sonder moeite. Dan probeer jy die omgekeerde, van EC2 na die adres wat aan die kliënt toegeken is, en dit hang of weier. Daardie asimmetrie is selde 'n ontbrekende sekuriteitsgroepreël. Op 'n Client VPN-eindpunt wat met VPC-subnette geassosieer is, vertaal AWS IPv4-kliëntbronne na die eindpunt se netwerkkoppelvlak, so daar is geen inkomende VPC-adres wat jou skootrekenaar verteenwoordig nie.
Begin met wat die opname wys
Neem 'n opname op die EC2-gasheer terwyl die kliënt verbind, en lees die bronadres wat die toepassing werklik sien. As dit die VPC-kant-eindpuntkoppelvlak is eerder as 'n adres uit die kliëntpoel, is die vertaling bevestig voordat jy 'n enkele reël verander.
Die kliëntpoel is 'n toekenningsreeks, nie 'n subnet met 'n terugroete nie. Dit is die onderskeid waar die meeste van hierdie ondersoeke verkeerd loop.
Die vertaling wat die asimmetrie verduidelik
Drie strome word met mekaar verwar, en net een van hulle is die een wat mense toets.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Die beskrywing van die Client VPN-komponente stel dit duidelik dat IPv4-kliëntbronne na die eindpuntkoppelvlak vertaal word, wat genoeg is om te sien waarom die middelry niks het om mee te pas nie.
'n Nuwe verbinding benodig 'n roete, 'n adresbepalingstap en 'n magtigingsbesluit. Vertaalingstoestand uit iemand anders se sessie lewer nie een van die drie nie.
Waarom 'n antwoord nie 'n nuwe verbinding is nie
'n TCP-antwoord word teen 'n bestaande inskrywing gepas, en daarom werk die terugpad sonder enige inkomende reël. 'n Nuwe SYN van die EC2-gasheer het geen inskrywing om teen te pas nie, so dit word 'n gewone uitgaande poging na 'n bestemming wat die VPC nie weet hoe om te bereik nie.
Dit is ook waarom om dit as verkeer wat net een rigting gaan te beskryf, misleidend is. Terugkeerverkeer vloei voortdurend in hierdie sessies. Inisiasie is die deel sonder 'n pad.
Wat steeds 'n sessie breek wat behoort te werk
Sekuriteitsgroepe, netwerk-ACL's en die skootrekenaar se eie vuurmuur maak almal saak vir die verbindings wat behoort te slaag. 'n Mislukte ping vertel die minste, want ICMP-beleid is dikwels apart van die TCP-beleid waarvoor jy sorg.
Skryf daardie reëls teen die vertaalde bron, nie die kliëntadres nie. Reëls wat op die adres gesleutel is wat nooit op die draad verskyn nie, is die algemeenste selfveroorsaakte mislukking in hierdie ontwerp.
Wanneer die VPC werklik die gesprek moet begin
As 'n diens 'n werkstasie moet inlig, draai die rigting om en laat die kliënt 'n aanhoudende uitgaande kanaal hou waarop die diens antwoord. As 'n hele afgeleë netwerk vanaf die VPC bereikbaar moet wees, kies 'n argitektuur wat sy prefikse en toegangsbeleid publiseer eerder as om aan te neem Client VPN doen dit reeds. Kliënt-tot-kliënt-toegang is 'n derde, nouer geval met sy eie roete- en magtigingsobjekte. Nie een hiervan is 'n merkblokkie op die bestaande eindpunt nie.
Hou ook die omvang van die IPv4-verduideliking eerlik. Huidige AWS-dokumentasie skei IPv6, waar daardie vertaling nie toegepas word nie, en ander aanhegtingsmodelle wat anders roeteer.
Toets in drie gemerkte stappe: die kliënt open 'n toegelate sessie, die VPC-diens antwoord daardie sessie, en 'n VPC-gasheer open 'n nuwe sessie na die kliënt. Dat die eerste twee slaag terwyl die derde misluk, is die verwagte vorm van hierdie ontwerp, nie 'n fout om met vuurmuurreëls te jag nie.