Кой пакет трябва да съпоставя политиката за VPN с два WAN?

Заявките да се маршрутизира VPN през втория ъплинк описват поне две различни задачи, а политиката, която поправя едната, не засяга другата. В първата задача криптираният транспорт между две крайни точки се премества на друг WAN адрес. Във втората дешифрираният поток на свързан потребител излиза към друг следващ хоп. И двете са законни, и двете използват маршрутизация и всяка се нуждае от съвпадение на пакет, който съществува в точката, където се взема решението. Преминете проверките по-долу по ред, защото първата определя кой пакет трябва да назовават следващите правила.

Назовете двата разговора

Представете си отдалечен служител, свързан към офисен шлюз, който отваря HTTPS към вътрешен сървър за приложения. В мрежата има два независими разговора и те имат различни адреси във всеки край. Външният разговор тече между двете крайни точки на VPN: от адреса на шлюза до адреса на партньора, с какъвто протокол и порт е договорило внедряването. Вътрешният разговор тече от адреса, зададен на клиента, до адреса на сървъра за приложения на порт 443.

Портът на местоназначение на приложението не е транспортният порт на VPN и никакво количество политики върху TCP 443 няма да премести тунела. По същия начин правило, което пренасочва транспортния адрес на партньора, не казва нищо за това накъде отива HTTP заявката на този потребител след дешифриране. Запишете двата разговора с реалните им адреси, преди да пипате правило, защото повечето объркване в тази област идва от това, че се назовава едното, а се конфигурира другото.

Открийте къде вашата политика наистина вижда пакета

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

Ето защо един и същ фрагмент от конфигурация се държи различно на две платформи: точките на прикачване се различават и куката на политиката на доставчика може да стои преди или след стъпката на криптиране. Четете пътя на пакета за конкретния продукт, вместо да предполагате реда по схема на друг доставчик.

Потвърдете транспорта, който сте договорили

При IPsec с UDP инкапсулация RFC 3948 поставя ESP вътре в UDP и използва маркер, който не е ESP, за да остане IKE различим на споделения порт. Обикновеният ESP е IP протокол, а не TCP или UDP порт, така че правило на защитна стена, написано по номер на порт, изобщо няма да го съпостави. Това разграничение решава дали вашата WAN политика се нуждае от UDP правило, от правило за протокол или от двете.

Договорените стойности бият запомнените. Четете текущите портове и адреси на асоциацията от устройството, вместо да добавяте TCP 4500 или стар порт на доставчик за всеки случай, което прихваща несвързан трафик и скрива истинския проблем с класификацията.

Проверете обратния път, преди да се ангажирате

Успехът на изходящия трафик доказва половината от дизайна. Пакет, който се връща към пула от отдалечени клиенти, вече не се вижда под адреса на клиента, след като инкапсулацията го замени: външното местоназначение е транспортният адрес на партньора. Ако вторият ъплинк достига до този партньор през друг оператор, неговата транслация и филтриране може да не съвпадат с първия и асоциацията може да се нуждае от преизграждане, а не от мигриране.

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

Проверете двата слоя с два записа

Един запис на WAN интерфейса и един вътре в тунела решават въпроса по-бързо от всяко сравнение на конфигурации. Пуснете ги от шлюза, докато одобрен клиент изпълнява една заявка, и запазете двата файла.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

Първият запис трябва да покаже външния разговор да напуска интерфейса, който сте имали предвид, с очаквания адрес на източника. Вторият трябва да покаже вътрешния разговор веднъж, без дублиране, с адреса на клиента като източник и сървъра за приложения като местоназначение. Търсенето на маршрут потвърждава коя таблица би използвал маршрутизаторът за тази двойка източник и местоназначение и точно там обикновено се появява грешка в политиката. Ако някой от записите не се появи, точката на решение е някъде другаде, а не там, където е прикачено правилото, и поправката принадлежи там, а не в по-широко съвпадение.