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

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

Зваротны трафік са станам змяняе лік

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

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

Дзе файрвол бачыць расшыфраваныя пакеты

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

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

Асіметрычная маршрутызацыя ламае здагадку

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

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

Праверце абодва кірункі з рэальнымі адрасамі крыніц

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

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

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

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