VPN med lokacijama: katera smer v resnici potrebuje pravilo?

Oba konca poročata o vzpostavljenem tunelu, oddaljena podružnica odgovarja s prehoda, aplikacija pa uporabnikom na eni strani še vedno poteče. Običajen nasvet pravi, da dodajte pravilo požarnega zidu v obe smeri. Včasih je to prav, včasih podvoji pravilo, ki že obstaja, včasih pa prav drugo pravilo pokvari stanje. Kateri primer velja, je odvisno od tega, kje požarni zid vidi paket.

Povratni promet s stanjem spremeni število

Požarni zid s stanjem zabeleži zahtevo in spusti odgovor brez drugega pravila, zato je zasnova, ki potrebuje le eno pravilo, običajna. Seznam dostopa brez stanja nima takega spomina in odgovor mora biti izrecno dovoljen. Oba sta pravilna na svoji platformi, zato si nasveta nasprotujeta.

Preberite dokumentacijo o posredovanju za platformo pred seboj in preverite, ali je pravilnik, ki ga urejate, stanjski tam, kjer vidi paket. Izrecna zavrnitev vzpostavljenega prometa ali vrstni red pravil, ki ovrednoti odgovor pred tabelo stanj, spremeni delujočo zasnovo v uganko. Število pravil je podrobnost izvedbe, zahteva pa je, da se obe smeri dovoljenega pogovora lahko zaključita.

Kje požarni zid vidi dešifrirane pakete

V tunelu na osnovi pravilnikov lahko požarni zid ovrednoti šifriran paket pred dešifriranjem in dešifriran paket zatem, na različnih vmesnikih. Pravilo, napisano za napačni vmesnik, je prisotno, pravilno in se nikoli ne ujema. Tako lahko nabor pravil, kopiran iz delujoče namestitve, odpove na enaki strojni opremi.

IPsec na osnovi usmerjanja in večina sodobnih izvedb ponujata tunelski vmesnik, zato dešifriran paket prispe tja in veljajo običajna pravila vmesnika. Potrdite, kateri model uporablja namestitev, preden kopirate nabor pravil iz priročnika, napisanega za drugega. Tunelski vmesnik je tudi mesto, kamor pogledate, ko morate vedeti, ali je bil paket sploh dešifriran.

Asimetrično usmerjanje poruši predpostavko

Požarni zid s stanjem predpostavlja, da vidi obe polovici pogovora. Če se odgovor vrne skozi drug prehod, ta naprava nima stanja za zahtevo in jo zavrže po svojem pravilniku. Simptom je enosmerna napaka, ki je nobeno pravilo na pošiljateljski strani ne more popraviti. Sledite poti odgovora preden karkoli uredite.

Preverite pot odgovora, preden na obeh straneh dodate široko pravilo dovoljenja. Prenašanje vsega na vsakem vmesniku skrije napako usmerjanja in hkrati razširi dostop, kar je najslabša razpoložljiva kombinacija.

Preverite obe smeri s pravimi naslovi vira

Testirajte z naslovom, ki ga oddaljena stran dejansko vidi, ker lahko prevajanje povzroči, da pravilo vira ne ustreza ničemur. Zaženite zajem na obeh prehodih hkrati.

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

Zahteva, ki se na oddaljenem prehodu pojavi z nepričakovanim naslovom vira, pojasni pravilo, ki se nikoli ne ujema, odgovor, ki prispe na napačni vmesnik, pa pojasni neujemanje stanja. Nato preizkusite en cilj znotraj odobrenega obsega in enega zunaj njega, da bo meja prikazana, ne predpostavljena.

Zabeležite naslov vira po prevajanju, vmesnik, ki ga je uporabil dešifriran paket, in pravilo, ki se je ujemalo. Ta tri dejstva odgovorijo na naslednjo zahtevo brez ponavljanja celotne preiskave.