Nettsted-til-nettsted-VPN: hvilken retning trenger egentlig en regel?

Begge ender rapporterer en etablert tunnel, den fjerne avdelingen svarer fra gatewayen, og applikasjonen går fortsatt ut på tid for brukere på én side. Det vanlige rådet er å legge til en brannmurregel i begge retninger. Noen ganger er det riktig, noen ganger dupliserer det en regel som allerede finnes, og noen ganger er det den andre regelen som ødelegger tilstanden. Hvilket tilfelle som gjelder avhenger av hvor brannmuren ser pakken.

Stateful returtrafikk endrer antallet

En stateful brannmur registrerer forespørselen og slipper svaret gjennom uten en andre regel, så et design som bare trenger én regel er normalt. En stateless tilgangsliste har ingen slik hukommelse, og svaret må tillates eksplisitt. Begge er korrekte på sin egen plattform, og derfor er rådene motstridende.

Les videresendingsdokumentasjonen for plattformen foran deg, og kontroller om policyen du redigerer er stateful der den ser pakken. En eksplisitt nektelse for etablert trafikk, eller en regelrekkefølge som vurderer svaret før tilstandstabellen, gjør et fungerende design forvirrende. Antallet regler er en implementasjonsdetalj, mens kravet er at begge retninger av en tillatt samtale kan fullføres.

Hvor brannmuren ser dekrypterte pakker

I en policybasert tunnel kan brannmuren vurdere den krypterte pakken før dekryptering og den dekrypterte pakken etterpå, på forskjellige grensesnitt. En regel skrevet for det feil grensesnittet er til stede, korrekt og blir aldri matchet. Slik kan et regelsett kopiert fra en fungerende utrulling feile på identisk maskinvare.

Rutebasert IPsec og de fleste moderne implementasjoner presenterer et tunnelgrensesnitt, så den dekrypterte pakken ankommer der og vanlige grensesnittregler gjelder. Bekreft hvilken modell utrullingen bruker før du kopierer et regelsett fra en veiledning skrevet for den andre. Tunnelgrensesnittet er også stedet å se når du trenger å vite om en pakke i det hele tatt ble dekryptert.

Asymmetrisk ruting bryter antakelsen

En stateful brannmur antar at den ser begge halvdeler av samtalen. Hvis svaret kommer tilbake gjennom en annen gateway, har den enheten ingen tilstand for forespørselen og dropper den etter sin egen policy. Symptomet er en enveis feil som ingen regel på sendersiden kan reparere. Følg svarveien før du redigerer noe.

Kontroller svarveien før du legger til en bred tillatelsesregel på begge sider. Å tolerere alt på hvert grensesnitt skjuler rutingfeilen og utvider tilgangen samtidig, som er den verste kombinasjonen som finnes.

Kontroller begge retninger med ekte kildeadresser

Test med adressen den fjerne siden faktisk ser, siden oversettelse kan gjøre at en kilderegel ikke matcher noe som helst. Kjør opptaket på begge gatewayene 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ørsel som dukker opp på den fjerne gatewayen med en uventet kildeadresse forklarer en regel som aldri matcher, og et svar som ankommer på feil grensesnitt forklarer et tilstandsavvik. Test deretter én destinasjon innenfor det godkjente omfanget og én utenfor, slik at grensen blir demonstrert i stedet for antatt.

Noter kildeadressen etter oversettelse, grensesnittet den dekrypterte pakken brukte, og regelen som ble matchet. Disse tre fakta besvarer neste sak uten å gjenta hele undersøkelsen.