Nettstad-til-nettstad-VPN: kva retning treng eigentleg ein regel?

Begge endar rapporterer ein etablert tunnel, den fjerne avdelinga svarar frå gatewayen, og applikasjonen går framleis ut på tid for brukarar på éi side. Det vanlege rådet er å leggje til ein brannmurregel i begge retningar. Nokre gonger er det riktig, nokre gonger dupliserer det ein regel som allereie finst, og nokre gonger er det den andre regelen som øydelegg tilstanden. Kva tilfelle som gjeld, kjem an på kvar brannmuren ser pakken.

Stateful returtrafikk endrar talet

Ein stateful brannmur registrerer førespurnaden og slepp svaret gjennom utan ein andre regel, så eit design som berre treng éin regel er normalt. Ei stateless tilgangsliste har inga slik hukommelse, og svaret må løyvast eksplisitt. Begge er korrekte på si eiga plattform, og difor er råda motstridande.

Les vidaresendingsdokumentasjonen for plattforma framfor deg, og kontroller om policyen du redigerer er stateful der han ser pakken. Ei eksplisitt nekting for etablert trafikk, eller ei regelrekkjefølgje som vurderer svaret før tilstandstabellen, gjer eit fungerande design forvirrande. Talet på reglar er ein implementasjonsdetalj, medan kravet er at begge retningane av ein tillaten samtale kan fullførast.

Kvar brannmuren ser dekrypterte pakkar

I ein policybasert tunnel kan brannmuren vurdere den krypterte pakken før dekryptering og den dekrypterte pakken etterpå, på ulike grensesnitt. Ein regel skriven for det feil grensesnittet er til stades, korrekt og blir aldri treft. Slik kan eit regelsett kopiert frå ei fungerande utrulling feile på identisk maskinvare.

Rutebasert IPsec og dei fleste moderne implementasjonar presenterer eit tunnelgrensesnitt, så den dekrypterte pakken kjem dit og vanlege grensesnittreglar gjeld. Stadfest kva modell utrullinga brukar før du kopierer eit regelsett frå ei rettleiing skriven for den andre. Tunnelgrensesnittet er òg staden å sjå når du treng å vite om ein pakke i det heile vart dekryptert.

Asymmetrisk ruting bryt føresetnaden

Ein stateful brannmur føreset at han ser begge halvdelar av samtalen. Viss svaret kjem tilbake gjennom ein annan gateway, har den eininga ingen tilstand for førespurnaden og droppar han etter sin eigen policy. Symptomet er ein einvegs feil som ingen regel på sendarsida kan reparere. Følg svarvegen før du redigerer noko.

Kontroller svarvegen før du legg til ein brei løyveregel på begge sider. Å tole alt på kvart grensesnitt skjuler rutingfeilen og utvidar tilgangen samstundes, som er den verste kombinasjonen som finst.

Kontroller begge retningar med ekte kjeldeadresser

Test med adressa den fjerne sida faktisk ser, sidan omsetjing kan gjere at ein kjelderegel ikkje passar med noko som helst. Køyr opptaket på begge gatewayane samstundes.

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

Ein førespurnad som dukkar opp på den fjerne gatewayen med ei uventa kjeldeadresse forklarer ein regel som aldri passar, og eit svar som kjem inn på feil grensesnitt forklarer eit tilstandsavvik. Test deretter éin destinasjon innanfor det godkjende omfanget og éin utanfor, slik at grensa blir demonstrert i staden for antatt.

Noter kjeldeadressa etter omsetjing, grensesnittet den dekrypterte pakken brukte, og regelen som vart treft. Desse tre fakta svarar på neste sak utan å gjenta heile undersøkinga.