VPN site-la-site funcționează doar într-un sens: două defecțiuni diferite

Site-ul A ajunge la B, B nu ajunge la A, iar tunelul pare în regulă în ambele sensuri. Înainte să atingeți tunelul, stabiliți care defecțiune este reală. O conexiune nouă pornită pe B și refuzată și un răspuns la o conexiune pornită pe A care nu sosește niciodată produc reclamații similare și diagnostice complet diferite. Una este o problemă de politică sau de rută pe traseu; cealaltă este o problemă de cale de întoarcere sau de stare pentru traficul care era deja permis.

Această distincție decide ce comenzi merită rulate.

Două defecțiuni care par identice

În primul caz, gazda B trimite un SYN către A și nimic nu se întoarce. În al doilea, gazda A deschide o sesiune cu succes și răspunsul dispare pe drumul de întoarcere. Ambii utilizatori spun că legătura este unidirecțională și ambii descriu un pachet care a dispărut, așa că descrierea singură nu le poate separa.

Întrebați care parte a pornit încercarea eșuată. Acest singur fapt elimină jumătate din cauzele posibile.

Apoi verificați că testul a folosit aceleași gazde și același serviciu tot timpul. Un ping dintr-o parte și o conexiune la un folder partajat din cealaltă testează două lucruri diferite, iar un diagnostic făcut din gateway poate alege o adresă de tunel pe care niciun trafic de utilizator nu o folosește.

Primul caz: lipsește calea de întoarcere

Un server la distanță care răspunde prin alt gateway implicit poate primi cererea și ruta răspunsul în altă parte. Firewall-urile cu urmărire de stare aruncă atunci răspunsul asimetric pentru că nu corespunde unui flux stabilit, ceea ce arată exact ca un sens care nu a funcționat niciodată. Traducerea adaugă o altă variantă: destinația vede o sursă tradusă și răspunde acesteia, așa că o regulă scrisă pentru adresa originală nu se potrivește niciodată.

Verificați adresa pe care destinația o observă cu adevărat după traducere, și ruta de întoarcere pentru acea adresă, nu pentru subrețeaua originală.

Al doilea caz: politica nu a permis niciodată

Cazul opus este mai simplu și mai frecvent decât pare: un birou trebuie să consume un serviciu central și să nu inițieze niciodată conexiuni către centru. Acea asimetrie este o decizie deliberată de acces, iar tunelul funcționează conform proiectării. Citiți politica de acces înainte de a schimba orice setare a tunelului. Documentul, nu captura de pachete, arată ce sens a fost intenționat. O captură poate arăta doar ce s-a întâmplat, nu ce era autorizat.

Dacă inițierea bidirecțională este cu adevărat necesară, adăugați permisiunea pentru serviciul concret prin setul de reguli acceptat de platformă. A face fiecare subrețea de încredere reciprocă pentru a repara o aplicație transformă o cerință îngustă într-o permisiune largă, iar acest schimb este rar revizuit ulterior.

Comparați înainte și după pe aceleași gazde

Urmăriți ambele capete ale aceleiași încercări, nu două încercări separate. Capturați pe gateway-ul gazdei care inițiază și pe destinație, apoi comparați ce a intrat, ce a ieșit și ce adresă a văzut partea îndepărtată.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Dacă captura de pe destinație arată cererea cu o adresă sursă neașteptată, răspunsul este în traducere sau rutare, nu în politica de securitate a tunelului. Dacă destinația nu arată nicio cerere, pachetul nu a traversat niciodată calea protejată.

După o corecție, repetați testul identic de pe aceeași gazdă și confirmați că accesul nelegat este încă refuzat. Un statut de tunel “established” nu susține singur niciuna dintre cele două concluzii.