Који пакет мора да погоди VPN политика са два WAN-а?

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

Именујте два разговора

Замислите удаљеног радника повезаног на канцеларијски gateway, који отвара HTTPS ка интерном апликацијском серверу. На мрежи су два независна разговора, и они на сваком крају имају различите адресе. Спољни разговор тече између две VPN крајње тачке: од адресе gateway-а до адресе партнера, са оним протоколом и портом које је имплементација договорила. Унутрашњи разговор тече од адресе додељене клијенту до адресе апликацијског сервера на порту 443.

Одредишни порт апликације није транспортни порт VPN-а, и никаква количина политике на TCP 443 неће померити тунел. Исто тако, правило које преусмерава транспортну адресу партнера не говори ништа о томе куда иде HTTP захтев тог корисника након дешифровања. Запишите оба разговора са њиховим стварним адресама пре него што додирнете правило, јер већина забуне у овој области долази из тога што се једно именује а друго конфигурише.

Пронађите где ваша политика заиста види пакет

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

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

Потврдите транспорт који сте договорили

За IPsec инкапсулиран у UDP, RFC 3948 ставља ESP унутар UDP-а и користи ознаку која није ESP да IKE остане разлучив на заједничком порту. Обични ESP је IP протокол, а не TCP или UDP порт, па правило заштитног зида написано према броју порта уопште га неће погодити. Ова разлика одлучује треба ли вашој WAN политици UDP правило, правило протокола или обоје.

Договорене вредности побеђују запамћене. Читајте тренутне портове и адресе асоцијације са уређаја уместо да додајете TCP 4500 или стари порт произвођача за сваки случај, што хвата неповезан саобраћај и скрива стварни проблем класификације.

Проверите повратну путању пре него што се обавежете

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

Стање превода мрежних адреса је уобичајена жртва промене WAN-а. Забележите изабрани аплинк, очекивану спољну изворну адресу, превод у употреби и доступност партнера назад ка њој, па држите транспорт доступним без слања у тунел који га носи.

Проверите оба слоја с два снимка

Један снимак на WAN интерфејсу и један унутар тунела решавају питање брже од било ког поређења конфигурација. Покрените их са gateway-а док одобрени клијент извршава један захтев, и сачувајте оба фајла.

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

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