VPN рута или правило заштитног зида: шта одбацује пакет?

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

Две одлуке, један пакет, два власника

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

Филтрирање је одвојено. На Linux домаћину netfilter куке деле саобраћај према томе за кога је пакет: излаз напушта машину, улаз се на њој завршава, прослеђивање пролази кроз њу. Мрежном пролазу који прихвата VPN клијенте и усмерава их на LAN потребна је путања прослеђивања, и то је управо ланац који већина подразумеваних конфигурација оставља празан.

Избор извора припада истој одлуци и ту се крије већина неусклађености. Језгро бира изворну адресу са излазног интерфејса осим ако рута не наведе једну, па правило филтера написано за LAN подмрежу никада не одговара пакету који излази са адресом тунела.

Прочитајте шта је претрага заиста изабрала

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

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN клијенти често инсталирају правила политике на приоритетима испод главне табеле, па чиста главна табела сама по себи ништа не доказује. Упоредите приоритете правила са табелама које бирају и проверите да ли тунелска рута преживљава поновно повезивање уместо да се једном ручно дода.

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

Филтрирање се примењује на куки, а не на рути

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

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

Пошаљите сонду путем који клијент користи

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

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

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

Поставите сваку промену тамо где преживљава поновно повезивање

Рута додата са ip route add живи док интерфејс не падне. Сачувајте је у профилу везе: NetworkManager прихвата додатне руте на вези, а netplan их чува између покретања. Исто правило важи за изузетак заштитног зида на страни клијента, који нестаје после следећег поновног учитавања.

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

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