Pingul din gateway-ul IPsec folosește o altă adresă sursă

Trimiteți ping către partea îndepărtată din gateway-ul IPsec, nu primiți răspuns și trageți concluzia că tunelul este stricat, în timp ce fiecare sarcină de lucru din spatele gateway-ului transportă trafic normal. Cele două rezultate nu se contrazic. Un ping pornit pe gateway este un pachet cu sursă locală, iar gateway-ul alege o adresă sursă din propriul tabel de rutare. Această alegere poate diferi de adresele pe care le folosește traficul real al site-ului, ceea ce schimbă ce politică se potrivește și ce rută de întoarcere se aplică. Decideți ce trebuie să dovedească testul înainte de a citi ceva în rezultatul lui.

Trei întrebări diferite la care un ping poate răspunde

Prima întrebare este dacă partea îndepărtată este accesibilă măcar din acest host. A doua este dacă selectorii tunelului sau politica bazată pe rute admit trafic dintr-o anumită sursă. A treia este dacă traficul redirecționat dintr-o sarcină de lucru din spatele gateway-ului funcționează de la un capăt la altul. O singură comandă nu poate răspunde la toate trei, iar adresa sursă este ce le separă.

Alegeți mai întâi întrebarea. Altfel, un ping eșuat devine dovada teoriei pe care o aveați deja.

De ce alege gateway-ul o adresă la care nu vă așteptați

Când faceți ping la o destinație, stiva locală alege o sursă din ruta care i se potrivește. Pe un tunel bazat pe rute aceasta poate fi adresa de legătură a interfeței tunelului, care în multe proiecte de site este o pereche 169.254.x.x aleasă pentru saltul punct-la-punct. Acele adrese există pentru ca legătura să funcționeze; ele nu sunt anunțate ca rețele sursă de aplicații în partea îndepărtată.

Astfel, partea îndepărtată poate primi o cerere de ecou de la o adresă către care nu are rută de întoarcere, sau de la una căreia nu i se potrivește niciun selector. Tunelul poate fi sănătos și pingul poate eșua totuși, și exact acesta este falsul negativ despre care este acest articol.

Alegeți sursa în mod deliberat

Pe un gateway Linux controlat, alegeți o sursă care este deja atribuită local: ping -c 4 -I 10.30.0.1 10.40.0.20. Adresele de aici sunt ilustrative, așa că înlocuiți-le cu adresa internă reală a gateway-ului și cu o destinație îndepărtată reală, și confirmați că sursa pe care o alegeți aparține acestui dispozitiv și este admisă de politica site-ului.

Nu împrumutați adresa unei sarcini de lucru pentru test. Prefacerea unui host care nu este atribuit gateway-ului creează un rezultat pe care nimeni nu îl poate reproduce, iar pe unele stive eșuează în moduri care arată ca o defecțiune a tunelului.

Citiți calea de întoarcere, nu doar cererea

Verificați ce sursă ajunge de fapt la destinația îndepărtată, inclusiv orice traducere deliberată pe parcurs. Apoi verificați ruta de întoarcere a părții îndepărtate către acea sursă și selectorii sau politica ce o permit. O cerere care sosește cu o sursă neașteptată este o problemă de rutare și politică, nu de criptografie.

Aici și o captură ajută mai mult decât un alt ping: arată sursa pe care a văzut-o partea îndepărtată, iar aceea este adresa pe care trebuie să o atingă răspunsul ei.

Apoi testați sarcina de lucru

Testul decisiv este un ping de la un host obișnuit din spatele gateway-ului la un host obișnuit din spatele gateway-ului îndepărtat. Aceasta exersează rolul de redirecționare al gateway-ului, sursa reală a aplicației și calea de întoarcere adevărată, care este fluxul de care le pasă utilizatorilor.

Țineți rezultatele separat în notițe: accesibilitatea din gateway, admiterea politicii pentru o sursă aleasă și traficul redirecționat. Un ping fixat cu succes este o dovadă utilă că tunelul transportă ceva; nu este dovada că fiecare flux redirecționat funcționează. Iar o sursă de gateway aleasă automat care nu poate fi atinsă nu este dovada că tunelul site-ului este căzut.

Nu adăugați o rută generală pentru 169.254.0.0/16 doar ca să obțineți un răspuns de diagnostic. Asta schimbă un test înșelător pe o decizie de rutare permanentă, iar următoarea persoană o moștenește fără context.