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

Телефоните на огранокот треба да излегуваат низ централата, додека преносните сметачи на огранокот продолжуваат да го користат локалниот WAN, и само политиката за рутирање нема да го обезбеди тоа. Рутата на огранокот може да го избере тунелот, но политиката за тунел мора да го прифати сообраќајот, централата мора да го проследи и преведе, а одговорот мора да се врати по истиот пат. Испуштете било кој од овие три и симптомот ќе биде подмножество клиенти што го губат интернетот токму додека тунелот е активен.

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

Политиката за рутирање се совпаѓа по извор, затоа изворот мора да биде стабилен пред сѐ друго. Ставете ги избраните уреди во група адреси што ја одржува администратор или, подобро, на посветен сегмент чие членство го следи улогата на уредот. Кога вообичаената промена на DHCP може да премести совпадната адреса на друга машина, политиката тивко избира погрешен клиент, а првиот извештај обично е за бавно прелистување што всушност е заобиколен пат.

Именувајте ја групата по политиката на која ѝ служи, а не по кат или оддел, бидејќи правилото за рутирање ќе ги надживее и двете. Запишете кои уреди се во неа и кој смее да додаде еден.

Додајте ја политиката на огранокот, потоа брани го нејзиниот редослед

На SonicWall на огранокот, политиката за рута ја избира групата извори, ги именува предвидените одредишта и ја поставува интерфејсот на тунелот како порта, за што постои поддржаниот дизајн на интерфејс на тунел. Држете ги правилата за локални и приватни одредишта над широкото интернет правило, бидејќи првото совпаѓање победува, а приватен префикс турнат во тунелот пристигнува во централата само за да биде отфрлен. Зачувајте ја и сопствената рута на ѕидот до неговиот VPN партнер, инаку транспортот на тунелот ќе ја следи политиката од која зависи. Ништо од ова не ве принудува да го конвертирате секој постоечки тунел заснован на политика; интерфејсот на тунел е еден поддржан избор меѓу неколку.

Редоследот е делот што се менува случајно. Секој што додава исклучок мора да го вметне над широкото правило, а секој што го уредува широкото правило може да го преврти целиот дизајн со едно зачувување. Запишете го предвидениот редослед покрај политиката и проверете го повторно по ажурирањата на фирмверот, бидејќи именувањето на интерфејсите и прикажувањето на политиките навистина се менуваат меѓу изданијата.

Завршете ја патеката во централата

Политиката за тунел во централата мора да го прифати сообраќајот што сега го избира рутата на огранокот. Меѓуканцелариски селектор ограничен на приватниот LAN на централата не е дозвола за пренесување произволни јавни одредишта, затоа политиката бара изворот на огранокот и опсегот на одредишта што навистина го мислите. Потоа централата го проследува дојдовниот сообраќај до својот интернет uplink според сопствените правила за пристап, а примерот за централен излез на SonicWall вклучува превод на изворот за оддалечената мрежа на централниот WAN. Без тој превод далечната страна гледа приватна адреса на огранокот и нема рута назад до неа.

Одговорите се другата половина од договорот. Тие мора да се вратат низ тунелот или низ преводот со состојба создаден за нив, а сообраќајот до приватни локации може да бара поинаков NAT третман од јавниот излез. Држете ги тие правила разливливи, бидејќи едно широко правило за превод што го крие секој внатрешен извор го прави подоцнежното логирање и решавање проблеми многу потешко за читање.

Одлучете што прави групата кога тунелот паѓа

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

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

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

Ping до централната порта го тестира погрешното, бидејќи потекнува од ѕидот, а не од избран клиент. Тестирајте од уреди и тестирајте три од нив: избран уред, обичен уред што треба да остане локален и еден што зависи од локални услуги.

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 во истиот премин, бидејќи клиент што го прашува резолверот на огранокот може да создаде барање со потекло од рутерот со различен извор и затоа различен пат.

Враќањето назад е зачуваниот редослед на политики плус групата адреси. Вратете го претходниот редослед, отстранете ја групата од политиката и повторно тестирајте ги двата класи уреди. Чувајте ја извезената конфигурација со записот за промената, бидејќи следниот инженер треба да знае кое правило било широкото пред некој да го уреди.