VPN de la sit la sit: care direcție are într-adevăr nevoie de o regulă?

Ambele capete raportează un tunel stabilit, sucursala îndepărtată răspunde din gateway, iar aplicația tot expiră pentru utilizatorii de pe o parte. Sfatul obișnuit spune să adăugați o regulă de firewall în ambele direcții. Uneori este corect, uneori duplică o regulă care există deja, iar uneori a doua regulă este cea care strică starea. Care caz se aplică depinde de locul unde firewallul vede pachetul.

Traficul de retur cu stare schimbă numărul

Un firewall cu stare înregistrează cererea și admite răspunsul fără o a doua regulă, așa că un design care are nevoie doar de o regulă este normal. O listă de acces fără stare nu are o asemenea memorie, iar răspunsul trebuie permis explicit. Ambele sunt corecte pe platforma lor, motiv pentru care sfaturile se contrazic.

Citiți documentația de redirecționare pentru platforma din fața dumneavoastră și verificați dacă politica pe care o editați este cu stare acolo unde vede pachetul. O interdicție explicită pentru traficul stabilit, sau o ordine a regulilor care evaluează răspunsul înaintea tabelului de stări, transformă un design funcțional într-unul enigmatic. Numărul de reguli este un detaliu de implementare, în timp ce cerința este ca ambele direcții ale unei conversații permise să se poată finaliza.

Unde vede firewallul pachetele decriptate

Într-un tunel bazat pe politici, firewallul poate evalua pachetul criptat înainte de decriptare și pachetul decriptat după aceea, pe interfețe diferite. O regulă scrisă pentru interfața greșită este prezentă, corectă și nu se potrivește niciodată. Așa se poate ca un set de reguli copiat dintr-o implementare funcțională să eșueze pe hardware identic.

IPsec bazat pe rute și majoritatea implementărilor moderne oferă o interfață de tunel, așa că pachetul decriptat ajunge acolo și se aplică regulile obișnuite de interfață. Confirmați ce model folosește implementarea înainte de a copia un set de reguli dintr-un ghid scris pentru celălalt. Interfața de tunel este și locul unde să priviți când trebuie să știți dacă un pachet a fost decriptat măcar.

Rutarea asimetrică sparge presupunerea

Un firewall cu stare presupune că vede ambele jumătăți ale conversației. Dacă răspunsul se întoarce prin alt gateway, acel dispozitiv nu păstrează stare pentru cerere și o aruncă conform propriei politici. Simptomul este o defecțiune unidirecțională pe care nicio regulă de pe partea expeditorului nu o poate repara. Urmați calea răspunsului înainte de a edita ceva.

Verificați ruta răspunsului înainte de a adăuga o regulă largă de permitere pe ambele părți. Tolerarea a tot pe fiecare interfață ascunde eroarea de rutare și lărgește accesul în același timp, ceea ce este cea mai rea combinație disponibilă.

Verificați ambele direcții cu adrese sursă reale

Testați cu adresa pe care partea îndepărtată o vede într-adevăr, deoarece traducerea poate face ca o regulă sursă să nu corespundă nimic. Rulați captura pe ambele gateway-uri simultan.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

O cerere care apare pe gateway-ul îndepărtat cu o adresă sursă neașteptată explică o regulă care nu se potrivește niciodată, iar un răspuns care ajunge pe interfața greșită explică o nepotrivire de stare. Apoi testați o destinație în domeniul aprobat și una în afara lui, astfel încât limita să fie demonstrată, nu presupusă.

Notați adresa sursă după traducere, interfața folosită de pachetul decriptat și regula care s-a potrivit. Aceste trei fapte răspund la următorul tichet fără a repeta întreaga investigație.