Насочване на отделна подмрежа на клон през интернет изхода на SonicWall в централата

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

Започнете с селектора, а не с маршрута

Маршрутната политика съпоставя по източник, затова източникът трябва да е стабилен преди всичко друго. Поставете избраните устройства в адресна група, която администратор поддържа, или по-добре — в отделен сегмент, чието членство следва ролята на устройството. Когато обичайната смяна на DHCP може да премести съпоставен адрес на друга машина, политиката безшумно избира грешния клиент и първият сигнал обикновено е за бавно сърфиране, което всъщност е обходен път.

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

Добавете политиката за клона, после защитете реда ѝ

На SonicWall в клона маршрутна политика избира групата източници, именува желаните дестинации и задава тунелния интерфейс като шлюз — точно за това съществува поддържаният дизайн с тунелен интерфейс. Дръжте правилата за локални и частни дестинации над широкото интернет правило, защото първото съвпадение печели, а частен префикс, бутнат в тунела, пристига в централата само за да бъде изхвърлен. Запазете и собствения маршрут на защитната стена до нейния VPN партньор, иначе транспортът на тунела ще следва политиката, от която зависи. Нищо от това не ви принуждава да преобразувате всеки съществуващ тунел, базиран на политика; тунелният интерфейс е един поддържан избор сред няколко.

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

Завършете пътя в централата

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

Отговорите са другата половина на договора. Те трябва да се върнат през тунела или през създадената за тях транслация със състояние, а трафикът към частни сайтове може да се нуждае от различно NAT третиране от публичния изход. Дръжте тези правила различими, защото едно широко правило за транслация, което скрива всеки вътрешен източник, прави по-късното регистриране и отстраняване на проблеми много по-трудни за четене.

Решете какво прави групата, когато тунелът падне

Ако централният изход е изискване, а не предпочитание, връщането към локалния WAN е нарушение на съответствието, дори потребителите да останат онлайн. SonicOS документира маршрут с отхвърляне на тунелния интерфейс като поддържания начин да се попречи на избран трафик да поеме по нежелан алтернативен път.

Съпоставете обхвата и приоритета на този маршрут с инсталираната версия и го тествайте, като свалите тунела, вместо да се доверявате на етикета. Група, която никога не бива да излиза локално, трябва да се проваля затворено, докато група, в която наличността е по-важна, може законно да се върне към локалния път; и двете са решения и нито едно не бива да се случва по подразбиране.

Проверете от три клиента, после се върнете чисто

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

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

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

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