VPN saidist saidini: milline suund vajab tegelikult reeglit?

Mõlemad otsad teatavad loodud tunnelist, kaugfiliaal vastab lüüsist, ja rakendus aegub siiski ühe poole kasutajate jaoks. Tavaline nõuanne ütleb lisada tulemüürireegel mõlemas suunas. Mõnikord on see õige, mõnikord dubleerib see juba olemasolevat reeglit, ja mõnikord on teine reegel see, mis oleku rikub. Milline juhtum kehtib, sõltub sellest, kus tulemüür paketti näeb.

Olekupõhine tagasiliiklus muudab arvu

Olekupõhine tulemüür registreerib päringu ja lubab vastuse ilma teise reeglita, nii et ainult ühte reeglit vajav disain on tavaline. Olekuta juurdepääsuloendil sellist mälu pole ja vastus tuleb selgesõnaliselt lubada. Mõlemad on oma platvormil õiged, mistõttu nõuanded on vastuolus.

Lugege edastamise dokumentatsiooni teie ees oleva platvormi kohta ja kontrollige, kas redigeeritav poliitika on olekupõhine seal, kus see paketti näeb. Selgesõnaline keeld loodud liiklusele või reeglite järjekord, mis hindab vastust enne olekutabelit, muudab töötava disaini mõistatuslikuks. Reeglite arv on rakendusdetail, samas kui nõue on, et lubatud vestluse mõlemad suunad saaksid lõppeda.

Kus tulemüür näeb dekrüpteeritud pakette

Poliitikapõhises tunnelis võib tulemüür hinnata krüpteeritud paketti enne dekrüpteerimist ja dekrüpteeritud paketti pärast seda, erinevatel liidestel. Vale liidese jaoks kirjutatud reegel on olemas, õige ja ei kattu kunagi. Nii võib töötavast juurutusest kopeeritud reeglistik identsel riistvaral ebaõnnestuda.

Marsruudipõhine IPsec ja enamik kaasaegseid rakendusi esitlevad tunneliliidest, nii et dekrüpteeritud pakett saabub sinna ja kehtivad tavalised liidese reeglid. Kinnitage, millist mudelit juurutus kasutab, enne kui kopeerite reeglistiku juhendist, mis on kirjutatud teise jaoks. Tunneliliides on ka koht, kuhu vaadata, kui peate teadma, kas pakett üldse dekrüpteeriti.

Asümmeetriline marsruutimine murrab eelduse

Olekupõhine tulemüür eeldab, et näeb vestluse mõlemat poolt. Kui vastus tuleb tagasi teise lüüsi kaudu, ei hoia see seade päringu jaoks olekut ja viskab selle oma poliitika järgi ära. Sümptom on ühesuunaline tõrge, mida ükski reegel saatval poolel ei suuda parandada. Jälgige vastuse teekonda enne millegi muutmist.

Kontrollige vastuse marsruuti enne laia lubamisreegli lisamist mõlemale poolele. Kõige talumine igal liidesel peidab marsruutimisvea ja laiendab samal ajal juurdepääsu, mis on halvim võimalik kombinatsioon.

Kontrollige mõlemat suunda tegelike lähteaadressidega

Testige aadressiga, mida kaugpool tegelikult näeb, sest tõlkimine võib panna lähteaadressi reegli mittemillegagi sobima. Käivitage püüdmine mõlemas lüüsis korraga.

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

Päring, mis ilmub kauglüüsis ootamatu lähteaadressiga, selgitab reeglit, mis kunagi ei kattu, ja vale liidesele saabuv vastus selgitab oleku mittevastavust. Seejärel testige ühte sihtkohta kinnitatud ulatuse sees ja ühte sellest väljas, et piir oleks näidatud, mitte eeldatud.

Kirjutage üles lähteaadress pärast tõlkimist, liides, mida dekrüpteeritud pakett kasutas, ja reegel, mis kattus. Need kolm fakti vastavad järgmisele piletile ilma kogu uurimist kordamata.