Site-til-site-VPN: hvilken retning har egentlig brug for en regel?

Begge ender rapporterer en etableret tunnel, den fjerne afdeling svarer fra gatewayen, og applikationen timeout'er stadig for brugere på den ene side. Det sædvanlige råd er at tilføje en firewallregel i begge retninger. Nogle gange er det rigtigt, nogle gange duplikerer det en regel, der allerede findes, og nogle gange er det den anden regel, der ødelægger tilstanden. Hvilket tilfælde der gælder, afhænger af, hvor firewallen ser pakken.

Stateful returtrafik ændrer antallet

En stateful firewall registrerer forespørgslen og tillader svaret uden en anden regel, så et design, der kun kræver én regel, er normalt. En stateless adgangsliste har ingen sådan hukommelse, og svaret skal tillades eksplicit. Begge er korrekte på deres egen platform, og derfor er rådene modstridende.

Læs videresendelsesdokumentationen for den platform, du har foran dig, og kontroller, om den politik, du redigerer, er stateful der, hvor den ser pakken. Et eksplicit afslag på etableret trafik eller en regelrækkefølge, der vurderer svaret før tilstandstabellen, gør et fungerende design forvirrende. Antallet af regler er en implementeringsdetalje, mens kravet er, at begge retninger af en tilladt samtale kan fuldføres.

Hvor firewallen ser dekrypterede pakker

I en politikbaseret tunnel kan firewallen vurdere den krypterede pakke før dekryptering og den dekrypterede pakke bagefter, på forskellige grænseflader. En regel skrevet til den forkerte er til stede, korrekt og bliver aldrig matchet. Det er sådan et regelsæt kopieret fra en fungerende udrulning kan fejle på identisk hardware.

Rutebaseret IPsec og de fleste moderne implementeringer præsenterer en tunnelgrænseflade, så den dekrypterede pakke ankommer dertil, og almindelige grænsefladeregler gælder. Bekræft, hvilken model udrulningen bruger, før du kopierer et regelsæt fra en vejledning skrevet til den anden. Tunnelgrænsefladen er også stedet at kigge, når du skal vide, om en pakke overhovedet blev dekrypteret.

Asymmetrisk routing bryder antagelsen

En stateful firewall antager, at den ser begge halvdele af samtalen. Hvis svaret vender tilbage gennem en anden gateway, har den enhed ingen tilstand for forespørgslen og dropper den efter sin egen politik. Symptomet er en ensrettet fejl, som ingen regel på afsendersiden kan reparere. Følg svarstien før du redigerer noget.

Kontroller svarstien, før du tilføjer en bred tilladelsesregel på begge sider. At tolerere alt på hver grænseflade skjuler routingfejlen og udvider adgangen samtidig, hvilket er den værste kombination, der findes.

Kontroller begge retninger med rigtige kildeadresser

Test med den adresse, den fjerne side faktisk ser, da oversættelse kan få en kilderegel til at matche ingenting. Kør optagelsen på begge gateways samtidig.

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

En forespørgsel, der dukker op på den fjerne gateway med en uventet kildeadresse, forklarer en regel, der aldrig matcher, og et svar, der ankommer på den forkerte grænseflade, forklarer et tilstandsmismatch. Test derefter én destination inden for det godkendte område og én uden for det, så grænsen bliver demonstreret i stedet for antaget.

Noter kildeadressen efter oversættelse, den grænseflade den dekrypterede pakke brugte, og den regel, der blev matchet. De tre fakta besvarer den næste sag uden at gentage hele undersøgelsen.