Bron-/bestemmingstoets is een hek, nie die hele VPN-pad nie
'n Deurvoerinstansie het AWS-toestemming nodig sowel as Linux-roetes en vuurmuurreels. Kontroleer bron-/bestemmingsvalidering op die instansie wat deurvoer.
Die VPN eindig op 'n EC2-instansie, jy kan daardie instansie se tonneladres bereik, en verkeer wat veronderstel is om daardeur na 'n ander private gasheer te gaan, verdwyn. Dit is twee verskillende toetse, en om hulle te vermeng mors ure. Die eerste vra of jy die instansie kan bereik; die tweede vra dat dit verkeer vir 'n bestemming wat nie sy eie is nie moet deurvoer, wat Linux-deurvoer, 'n vuurmuurbeleid, 'n roete aan die ander kant en 'n AWS-vlak toestemming vereis wat niks met die gasbedryfstelsel te doen het nie. Niks in die konsole vestig aandag op daardie verskil nie. Die simptoom lyk na 'n roetefout, en dit is gewoonlik nie.
Skei die twee toetse voordat jy iets verander
Om die poort te bereik bewys die tonnel, die roete na sy adres en die sekuriteitsgroep wat die uitruiling toelaat. Deurvoer vir 'n ander gasheer bewys niks daarvan nie: dit gebruik 'n ander bronadres, 'n ander bestemming en 'n instansie wat in 'n rol optree waarvoor dit nie noodwendig gebou is nie. Skryf die twee toetse afsonderlik neer en let op watter een misluk, want die regstelling vir elkeen is in 'n ander konsole. 'n Poortinstansie wat net gebou is om tonnele te beëindig, het geen rede om vir iets anders deur te voer nie, en sy verstekke weerspieël dit. Daarom het die tweede toets sy eie opstelling nodig eerder as 'n klein aanpassing aan die eerste.
'n Ping wat na die poort werk en 'n ping wat na die gasheer anderkant misluk, is nie 'n wisselvallige probleem nie. Dit is die verwagte gedrag van 'n instansie wat nie meegedeel is dat dit mag deurvoer nie.
Skryf die pad neer voordat jy aan 'n instelling raak
Teken die kliëntvoorvoegsel, die deurvoerinstansie of netwerkkoppelvlak, die teikensubnet en die antwoordroete aan. 'n VPC-roetetabelinskrywing wat na 'n instansie wys, stel nie die instansie se bedryfstelsel in om deur te voer nie, en 'n gasheer-kern met deurvoer geaktiveer skep nie 'n VPC-roete nie. Albei kante van daardie verhouding moet bestaan, en hulle word op verskillende plekke deur mense met verskillende toegang geredigeer.
Ondersoek dan die bron-/bestemmingstoets-instelling op die werklike deurvoerkomponent, nie op elke instansie in die VPC nie. AWS dokumenteer waarom 'n instansie wat verkeer vir ander deurvoer daardie toets gedeaktiveer moet hê, en ook waarom die instelling 'n per-instansie-besluit is eerder as 'n VPC-wye verstek.
Vier grense, en die toets is net een daarvan
Behandel die pad as vier vrae en beantwoord hulle in volgorde. Die eerste antwoord wat misluk, is waar die werk is, en nie een van die ander sal daarvoor vergoed nie.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
Die volgorde maak saak omdat dit goedkoop is om na te gaan: roetes is op een bladsy sigbaar, die toets is 'n enkele eienskap, en die bestemming se mening is gewoonlik die laaste ding waarvoor iemand vra.
Vertaling verander watter bron die bestemming sien
'n Geroteerde ontwerp behou die kliënt se bronadres, so die bestemming het 'n terugroete na die kliëntvoorvoegsel nodig. 'n Vertaalde ontwerp bied eerder die poort se adres aan, wat daardie vereiste verwyder en dit vervang met 'n toestandstabel op die poort. Besluit volgens die argitektuur wat jy beoog, eerder as om vertaling by te voeg omdat 'n onverwante voorbeeld dit gebruik het en dit gelyk het of dit werk.
As jy vertaal, beperk die reël tot die kliëntvoorvoegsel en die beoogde bestemming. As jy behou, bevestig dat die ander kant die roete werklik ken eerder as om te aanvaar dat dit een sal leer.
Toets vanaf die oorspronklike kliënt en hou dan die verandering
'n Versoek wat op die poort gegenereer word, kan slaag terwyl 'n deurgevoerde versoek misluk, want dit is 'n ander bron en 'n ander deurvoergeval. Herhaal ná 'n gerigte regstelling die presiese kliënt-tot-hulpbron-toets wat misluk het, vanaf dieselfde kliënt, en bevestig dat die antwoord terugkom eerder as net dat die versoek aangekom het.
Plaas laastens die instelling in die poort se bestuurde konfigurasie sodat 'n vervangingsinstansie dit ontvang. 'n Suksesvolle toets wat van 'n handmatige uitsondering afhang, is 'n toets wat by die volgende herbou verval, en die persoon wat dit ontdek het, sal nie daar wees om te onthou waarom nie.