Правила заштитног зида само за NEW не затварају сваки WAN пут
Одбијање NEW веза оставља успостављене токове и одговоре нетакнутим. Прочитајте стање conntrack-а, редослед правила и изузетке пре него што политику назовете затвореном.
Одбијање нових одлазних веза на WAN-у изгледа као политика која се затвара при неуспеху, али је уже обећање него што изгледа. Пакети који припадају већ постојећим токовима не одговарају јој, као ни многи одговори. Овај јаз је лако пропустити јер се правило чита као да покрива интерфејс, а не једно стање везе на њему. А читање подударања стања као пресуде ствара лажан осећај затворености.
Стање је услов подударања, не пресуда
Праћење веза класификује пакете према ономе што је заштитни зид већ видео, а не према ономе што апликација верује. Ток примећен у оба смера је успостављен и његови каснији пакети остају успостављени чак и када се рута испод њега промени са тунела на уобичајену одлазну линију. Одговор на долазну везу такође може бити успостављен саобраћај. Ти пакети никада поново не постају нови.
Зато правило ограничено на нове везе не може доказати да је сваки заштићени пакет блокиран. Оно оставља остала стања ономе што са њима ради остатак скупа правила, а то може бити дозвола постављена раније у ланцу.
Читајте правило у његовом окружењу
Широка дозвола за успостављен и повезан саобраћај постављена пре блокирања пушта пакет пре него што се блокирање уопште оцени. Уклањање услова стања из каснијег правила то неће променити, јер оцена никада не стиже до њега. Редослед одлучује исход, а подударање стања одлучује који пакети стижу до тог редоследа.
Прегледајте делотворни скуп правила, а не датотеку коју сте уређивали, укључујући скокове у друге ланце и све што платформа генерише. На рутеру којим управља iptables, излиставање ланца показује дефиниције правила, а ланци на које упућује такође морају да се прате. Изворни nftables систем захтева преглед сопственог скупа правила и приоритета кука, јер фирмвер ретко генерише идентичне ланце.
Бројачи показују које правило је заиста одговарало и обично су информативнији од снимања пакета направљеног после одлуке. Правило са нултим бројачем није достигнуто, шта год да наговештава његов положај.
Изразите забрану независно од стања
Ако група клијената никада не сме да стигне до интернета ван тунела, реците то директно уместо да то приближавате једним стањем. Правило мора да бира по извору, излазу и одредишту без зависности од стања везе и мора да стоји тамо где га ниједна ранија дозвола не може заобићи. Тада административни приступ и изузеци за локалну мрежу добијају своја изричита правила, па је намера видљива у политици.
Избор reject уместо drop мења начин на који не успева саобраћај који се подудара и не проширује скуп пакета које правило бира. Одбијена веза и тихо истека времена су различити симптоми који указују на исти избор.
Политика која намерно дозвољава одговоре на приступ започет издалека преко WAN-а је одбрањива. Само је треба тако описати, уместо да се представља као потпуна изолација само кроз тунел.
Проверите ко је заиста у групи
Пример обухвата прослеђени IPv4 саобраћај из једног префикса кроз један интерфејс. Не говори ништа о IPv6, другој одлазној линији или саобраћају који сам рутер ствара. Рутер који делује као DNS резолвер шаље своје упите ка вишем нивоу и они уопште не пролазе кроз ланац forward.
Потврдите да заштићени клијенти и даље имају адресе унутар изабраног префикса, јер уређај који је изашао из њега је директан случајно, а не по политици. Проширење блокирања на цео LAN без прегледа дизајна изузетака такође обично уклања вашу сопствену административну путању.
iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED
Затим испробајте стари ток поред новог. Нови покушај везе и већ активан двосмерни пренос понашају се другачије под овим правилом, и само тестирање оба показује какву политику заиста имате.