VPN између локација: који смер заиста захтева правило?

Обе стране пријављују успостављен тунел, удаљена филијала одговара са мрежног пролаза, а апликација ипак истиче за кориснике на једној страни. Уобичајен савет је да се дода правило заштитног зида у оба смера. Понекад је то тачно, понекад дуплира правило које већ постоји, а понекад је друго правило оно које квари стање. Који случај важи зависи од тога где заштитни зид види пакет.

Повратни саобраћај са стањем мења број

Заштитни зид са стањем бележи захтев и пропушта одговор без другог правила, па је дизајн коме треба само једно правило нормалан. Листа приступа без стања нема такву меморију, и одговор мора бити изричито дозвољен. Оба су тачна на својој платформи, и зато се савети противрече.

Прочитајте документацију о прослеђивању за платформу пред собом и проверите да ли је политика коју уређујете са стањем тамо где види пакет. Изричито одбијање успостављеног саобраћаја, или редослед правила који оцењује одговор пре табеле стања, претвара функционалан дизајн у загонетку. Број правила је детаљ имплементације, а захтев је да оба смера дозвољеног разговора могу да се заврше.

Где заштитни зид види дешифроване пакете

У тунелу заснованом на политикама, заштитни зид може да оцени шифровани пакет пре дешифровања и дешифровани пакет после, на различитим интерфејсима. Правило написано за погрешан интерфејс је присутно, тачно и никада се не поклапа. Тако скуп правила копиран са функционалног распореда може да закаже на идентичном хардверу.

IPsec заснован на рутирању и већина савремених имплементација пружају тунелски интерфејс, па дешифровани пакет стиже тамо и важе уобичајена правила интерфејса. Потврдите који модел распоред користи пре него што копирате скуп правила из водича написаног за други. Тунелски интерфејс је и место где се гледа када треба знати да ли је пакет уопште дешифрован.

Асиметрично рутирање крши претпоставку

Заштитни зид са стањем претпоставља да види обе половине разговора. Ако се одговор врати кроз други пролаз, тај уређај нема стање за захтев и одбацује га према сопственој политици. Симптом је једносмерни неуспех који ниједно правило на страни пошиљаоца не може да поправи. Пратите путању одговора пре него што било шта уредите.

Проверите руту одговора пре него што додате широко правило дозволе на обе стране. Толерисање свега на сваком интерфејсу крије грешку рутирања и истовремено проширује приступ, што је најгора могућа комбинација.

Проверите оба смера са стварним изворним адресама

Тестирајте са адресом коју удаљена страна заиста види, јер превођење може да учини да се правило извора не поклопи ни са чим. Покрените снимање на оба пролаза истовремено.

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

Захтев који се на удаљеном пролазу појави са неочекиваном изворном адресом објашњава правило које се никада не поклапа, а одговор који стигне на погрешан интерфејс објашњава неслагање стања. Затим тестирајте једну дестинацију унутар одобреног опсега и једну изван њега, да граница буде показана, а не претпостављена.

Забележите изворну адресу после превођења, интерфејс који је користио дешифровани пакет и правило које се поклопило. Ове три чињенице одговарају на следећи тикет без понављања целе истраге.