Firewall în cloud versus firewall pe gazdă pentru un server VPN

Permiteți portul VPN în politica din cloud și handshake-ul poate muri totuși pe instanță: oaspetele rulează propriul filtru și propria legare a listenerului, iar oricare dintre ele poate arunca ce a aprobat cloudul. Se întâmplă și invers, când o regulă de pe gazdă permite portul, iar o politică de deasupra îl aruncă prima. Doi proprietari, două seturi de reguli, o singură cale a pachetelor. Parcurgeți-o în ordine în loc să ghiciți la stratul cel mai suspect.

Începeți de la margine și mergeți spre interior

Ordinea este fixă: punct final public, interfața resursei, politica din cloud atașată, adresa oaspetelui, listenerul procesului, regulile locale de intrare. Fiecare etapă fie lasă pachetul să treacă, fie încheie investigația, de aceea începutul la oaspete pierde cel mai mult timp.

Traficul de client redirecționat este o etapă separată, inspectată după decapsularea tunelului. Stratul din cloud vede doar tunelul exterior, deci poate aproba o conexiune și totuși să nu aibă nimic de-a face cu o cerere către un serviciu intern. Un tunel care se conectează, dar nu ajunge la o gazdă internă, indică de obicei redirecționarea, nu un port închis.

Citiți politica din cloud înainte de a atinge oaspetele

Confirmați regula de intrare pentru portul VPN, protocolul ei și domeniul sursă care corespunde clientului de test. Verificați și lista de control al accesului a subrețelei: un al doilea filtru cu reguli și valori implicite proprii. Ambele trebuie să permită fluxul înainte ca un pachet să ajungă la instanță. Permisiune într-una și refuz în cealaltă este forma obișnuită a acestei erori.

Îngustați domeniul până când înseamnă ceva. Deschiderea portului VPN către tot internetul este ușor de dovedit și greu de apărat, în timp ce o regulă fixată pe o singură adresă se rupe când clientul de test își schimbă rețeaua. Notați identificatorul regulii și proprietarul politicii, ca următoarea modificare să fie trasabilă până la o persoană.

Confirmați listenerul, apoi lanțul de intrare

Pe instanță, verificați dacă procesul VPN este legat de adresa și portul pe care le așteptați, de exemplu cu ss -lntp 'sport = :1194'. Un demon legat doar de 127.0.0.1 acceptă clienți locali și nimic prin tunel, ceea ce din exterior arată exact ca un port filtrat.

Apoi citiți regulile locale în sintaxa pe care ați folosi-o pentru a le schimba, cum ar fi iptables -S INPUT sau nft list chain inet filter input. O regulă scrisă într-un fișier dar niciodată încărcată, sau o aruncare implicită fără permisiune potrivită, aruncă pachetele în tăcere. Pentru un gateway care redirecționează, verificați și setările de redirecționare și de cale inversă. Ele decid ce se întâmplă cu pachetele rutate prin instanță și nu adresate acesteia.

Cu stare într-un strat, fără stare în următorul

Grupurile de securitate își amintesc fluxurile pe care le-au permis și lasă răspunsurile să intre înapoi. Listele de control al accesului ale subrețelelor și multe firewalluri de gazdă nu țin o asemenea stare, așa că o regulă care acoperă doar direcția de ieșire lasă cererea să treacă și aruncă răspunsul. Nu duceți niciodată o presupunere despre traficul de retur între straturi fără a citi regula celui de-al doilea strat (second layer's rule).

Contoarele lămuresc asta mai repede decât citirea fiecărei reguli din cont. Un contor care urcă înseamnă că pachetul a ajuns și a fost aruncat acolo, iar unul înghețat la zero înseamnă că nu a ajuns niciodată atât de departe; iptables -vnL INPUT și nft list ruleset arată acele cifre când regulile au fost încărcate cu contoare.

Testați cu o sesiune nouă, nu cu una activă

Lăsați rețeaua sursă și profilul de test neatinse în timp ce comparați vizualizările și deschideți o conexiune nouă după fiecare modificare. A ajunge la consola web pe 443 nu spune nimic despre faptul că demonul VPN este legat de 1194, așa că testați portul de care aveți nevoie. O sesiune existentă este cel mai prost martor aici. Ea continuă să funcționeze în timp ce fiecare autentificare nouă este refuzată.

Înainte de a edita o politică la distanță, asigurați-vă o cale de întoarcere care nu depinde de calea pe care o schimbați. Apoi deschideți o a doua sesiune de administrare lângă testul VPN: una stabilită mai devreme poate supraviețui regulii care le blochează pe cele noi. Notați ambii proprietari ai politicilor ca nicio reconstrucție să nu restaureze jumătate din cale; dacă ambele straturi sunt de acord și tunelul tot eșuează, capturați pe interfața oaspetelui și verificați adresa și portul pe care clientul le folosește cu adevărat.