Plats-till-plats-VPN: vilken riktning behöver egentligen en regel?

Båda ändarna rapporterar en upprättad tunnel, den fjärranslutna filialen svarar från gatewayen, och programmet får fortfarande timeout för användare på ena sidan. Det vanliga rådet är att lägga till en brandväggsregel i båda riktningarna. Ibland är det rätt, ibland duplicerar det en regel som redan finns, och ibland är det den andra regeln som bryter tillståndet. Vilket fall som gäller beror på var brandväggen ser paketet.

Stateful returtrafik ändrar antalet

En stateful brandvägg registrerar förfrågan och släpper igenom svaret utan en andra regel, så en design som bara behöver en regel är normal. En stateless åtkomstlista har inget sådant minne, och svaret måste tillåtas uttryckligen. Båda är korrekta på sin egen plattform, och därför motsäger råden varandra.

Läs vidarebefordringsdokumentationen för plattformen framför dig och kontrollera om policyn du redigerar är stateful där den ser paketet. En uttrycklig nekning för etablerad trafik, eller en regelordning som utvärderar svaret före tillståndstabellen, gör en fungerande design gåtfull. Antalet regler är en implementeringsdetalj, medan kravet är att båda riktningarna av ett tillåtet samtal kan slutföras.

Där brandväggen ser dekrypterade paket

I en policybaserad tunnel kan brandväggen utvärdera det krypterade paketet före dekryptering och det dekrypterade paketet efteråt, på olika gränssnitt. En regel skriven för fel gränssnitt finns, är korrekt och matchas aldrig. Så kan en regeluppsättning kopierad från en fungerande installation misslyckas på identisk hårdvara.

Ruttbaserad IPsec och de flesta moderna implementationer presenterar ett tunnelgränssnitt, så det dekrypterade paketet anländer dit och vanliga gränssnittsregler gäller. Bekräfta vilken modell installationen använder innan du kopierar en regeluppsättning från en guide skriven för den andra. Tunnelgränssnittet är också stället att titta på när du behöver veta om ett paket alls dekrypterades.

Asymmetrisk routning bryter antagandet

En stateful brandvägg antar att den ser båda halvorna av samtalet. Om svaret kommer tillbaka genom en annan gateway har den enheten ingen tillstånd för förfrågan och släpper den enligt sin egen policy. Symtomet är ett enkelriktat fel som ingen regel på sändarsidan kan reparera. Följ svarets väg innan du redigerar något.

Kontrollera svarets rutt innan du lägger till en bred tillåtelseregel på båda sidor. Att tolerera allt på varje gränssnitt döljer routningsfelet och vidgar åtkomsten samtidigt, vilket är den sämsta kombinationen som finns.

Kontrollera båda riktningarna med riktiga källadresser

Testa med adressen som den fjärranslutna sidan faktiskt ser, eftersom översättning kan göra att en källregel inte matchar något alls. Kör inspelningen på båda gatewayerna samtidigt.

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 förfrågan som dyker upp på den fjärranslutna gatewayen med en oväntad källadress förklarar en regel som aldrig matchar, och ett svar som anländer på fel gränssnitt förklarar en tillståndsavvikelse. Testa sedan en destination inom det godkända omfånget och en utanför, så att gränsen demonstreras i stället för antas.

Anteckna källadressen efter översättning, gränssnittet som det dekrypterade paketet använde, och regeln som matchade. Dessa tre fakta besvarar nästa ärende utan att upprepa hela undersökningen.