VPN паміж пляцоўкамі працуе ў адзін бок: дзве розныя паломкі

Пляцоўка A дасягае B, B не можа дасягнуць A, а тунель выглядае спраўным у абодвух кірунках. Перш чым чапаць тунель, вызначце, якая паломка ў вас насамрэч. Новае злучэнне, пачатае на B і адхіленае, і адказ на злучэнне, пачатае на A, які ніколі не прыходзіць, даюць падобныя скаргі і цалкам розныя дыягназы. Адно гэта праблема палітыкі ці маршруту на шляху; другое праблема зваротнага шляху ці стану для трафіку, які ўжо быў дазволены.

Гэтае адрозненне вызначае, якія каманды варта запускаць.

Дзве паломкі, якія выглядаюць аднолькава

У першым выпадку хост B адпраўляе SYN на A, і нічога не вяртаецца. У другім хост A паспяхова адкрывае сесію, і адказ знікае на зваротным шляху. Абодва карыстальнікі кажуць, што канал аднабаковы, і абодва апісваюць пакет, які знік, таму само апісанне не можа іх раздзяліць.

Спытайце, які бок пачаў няўдалую спробу. Гэты адзіны факт прыбірае палову магчымых прычын.

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

Выпадак першы: зваротнага шляху няма

Аддалены сервер, які адказвае праз іншы шлюз па змаўчанні, можа атрымаць запыт і накіраваць адказ у іншае месца. Гэта міжсеткавыя экраны, што захоўваюць стан, потым адкідаюць асіметрычны адказ, бо ён не адпавядае ўсталяванаму патоку, і гэта выглядае менавіта як кірунак, які ніколі не працаваў. Трансляцыя дадае яшчэ адзін варыянт: атрымальнік бачыць трансляваны адрас крыніцы і адказвае на яго, таму правіла, напісанае для выходнага адраса, ніколі не спрацоўвае.

Праверце адрас, які атрымальнік насамрэч бачыць пасля трансляцыі, і зваротны маршрут менавіта для гэтага адраса, а не для выходнай падсеткі.

Выпадак другі: палітыка гэтага не дазваляла

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

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

Параўнайце да і пасля на тых жа хастах

Назірайце абодва канцы адной спробы, а не дзве асобныя спробы. Рабіце перахоп на шлюзе хаста, які ініцыюе, і на атрымальніку, затым параўнайце, што ўвайшло, што выйшла і які адрас бачыў далёкі бок.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Калі перахоп на атрымальніку паказвае запыт з нечаканым адрасам крыніцы, адказ у трансляцыі ці маршрутызацыі, а не ў палітыцы бяспекі тунеля. Калі атрымальнік не паказвае ніякага запыту, пакет ніколі не перасек абаронены шлях.

Пасля выпраўлення паўтарыце ідэнтычны тэст з таго ж хаста і пацвердзіце, што старонні доступ па-ранейшаму забаронены. Статус тунеля “established” сам па сабе не пацвярджае ні адной з дзвюх высноў.