Verificarea sursei/destinației este o singură poartă, nu tot drumul VPN
O instanță care redirecționează are nevoie de permisiune AWS, precum și de rute Linux și reguli de firewall. Verificați validarea sursei/destinației pe instanța care redirecționează.
VPN-ul se termină pe o instanță EC2, puteți ajunge la adresa de tunel a acelei instanțe, iar traficul care trebuia să treacă prin ea către un alt host privat dispare. Sunt două teste diferite, iar amestecarea lor pierde ore. Primul întreabă dacă puteți ajunge la instanță; al doilea cere ca ea să redirecționeze trafic pentru o destinație care nu este a ei, ceea ce necesită redirecționare în Linux, o politică de firewall, o rută pe partea cealaltă și o permisiune la nivel de AWS care nu are nimic de-a face cu sistemul de operare invitat. Nimic din consolă nu atrage atenția asupra acestei diferențe. Simptomul arată ca o defecțiune de rutare și de obicei nu este.
Separați cele două teste înainte de a schimba ceva
A ajunge la gateway dovedește tunelul, ruta către adresa lui și grupul de securitate care permite schimbul. Redirecționarea pentru alt host nu dovedește nimic din toate acestea: folosește o altă adresă sursă, o altă destinație și o instanță într-un rol pentru care nu a fost neapărat construită. Scrieți cele două teste separat și notați care eșuează, pentru că remedierea fiecăruia se află într-o altă consolă. O instanță gateway construită doar pentru a încheia tuneluri nu are niciun motiv să redirecționeze altceva, iar valorile implicite reflectă asta. De aceea al doilea test are nevoie de propria configurare, nu de o mică ajustare la primul.
Un ping care funcționează spre gateway și un ping care eșuează spre hostul de dincolo nu sunt o problemă intermitentă. Este comportamentul așteptat al unei instanțe căreia nu i s-a spus că poate redirecționa.
Scrieți traseul înainte de a atinge o setare
Notați prefixul clientului, instanța sau interfața de rețea de redirecționare, subrețeaua țintă și ruta de răspuns. O intrare din tabelul de rute al VPC care indică o instanță nu configurează sistemul de operare al instanței pentru redirecționare, iar un nucleu invitat cu redirecționarea activată nu creează o rută VPC. Ambele capete ale acestei relații trebuie să existe, iar ele sunt editate în locuri diferite de persoane cu acces diferit.
Apoi examinați setarea de verificare a sursei/destinației pe componenta reală de redirecționare, nu pe fiecare instanță din VPC. AWS documentează de ce o instanță care redirecționează trafic pentru alții trebuie să aibă acea verificare dezactivată și, de asemenea, de ce setarea este o decizie pentru fiecare instanță, nu o valoare implicită pentru tot VPC-ul.
Patru granițe, iar verificarea este doar una dintre ele
Tratați traseul ca patru întrebări și răspundeți în ordine. Primul răspuns care eșuează este locul unde se află munca, iar niciunul dintre celelalte nu îl va compensa.
| 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? |
Ordinea contează pentru că verificarea este ieftină: rutele se văd pe o singură pagină, verificarea este un singur atribut, iar părerea destinației este de obicei ultimul lucru pe care îl întreabă cineva.
Traducerea schimbă ce sursă vede destinația
Un design cu rutare păstrează adresa sursă a clientului, așa că destinația are nevoie de o rută de întoarcere către prefixul clientului. Un design tradus prezintă în schimb adresa gateway-ului, ceea ce elimină acea cerință și o înlocuiește cu un tabel de stări pe gateway. Decideți conform arhitecturii pe care o intenționați, în loc să adăugați traducere pentru că un exemplu nelegat a folosit-o și a părut să funcționeze.
Dacă traduceți, limitați regula la prefixul clientului și la destinația dorită. Dacă păstrați, confirmați că cealaltă parte cunoaște într-adevăr ruta, în loc să presupuneți că va învăța una.
Testați de la clientul original, apoi păstrați modificarea
O cerere generată pe gateway poate reuși în timp ce o cerere redirecționată eșuează, pentru că este altă sursă și alt caz de redirecționare. După o corecție țintită, repetați testul exact client-către-resursă care a eșuat, de la același client, și confirmați că răspunsul se întoarce, nu doar că cererea a ajuns.
În final, puneți setarea în configurația administrată a gateway-ului, astfel încât o instanță de înlocuire să o primească. Un test reușit care depinde de o excepție manuală este un test care expiră la următoarea reconstrucție, iar persoana care l-a descoperit nu va fi acolo să-și amintească de ce.