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

Заявка, която се появи на отдалечения шлюз с неочакван адрес на източника, обяснява правило, което никога не се съпоставя, а отговор, пристигащ на грешния интерфейс, обяснява несъответствие в състоянието. След това тествайте една дестинация в одобрения обхват и една извън него, за да бъде границата демонстрирана, а не предположена.

Запишете адреса на източника след транслацията, интерфейса, който дешифрираният пакет е използвал, и правилото, което е съвпаднало. Тези три факта отговарят на следващия тикет, без да се повтаря цялото разследване.

Подобни статии