Які пакет павінна супастаўляць палітыка 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

Першы запіс павінен паказаць знешнюю размову, якая пакідае менавіта той інтэрфейс, які вы мелі на ўвазе, з чаканым адрасам крыніцы. Другі павінен паказаць унутраную размову адзін раз, без дублявання, з адрасам кліента ў якасці крыніцы і серверам прыкладанняў у якасці прызначэння. Пошук маршруту пацвярджае, якую табліцу маршрутызатар выкарыстаў бы для гэтай пары крыніца і прызначэнне, і менавіта там звычайна выяўляецца памылка палітыкі. Калі які-небудзь запіс не з'явіўся, пункт рашэння знаходзіцца не там, да чаго было прывязана правіла, і выпраўленне належыць туды, а не ў больш шырокае супадзенне.