Сайтавы VPN працуе, але журналы ASA не прыходзяць: праверце адрас крыніцы

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

Што прыходзіць, а што не

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

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

Згенераванае паведамленне — гэта не перанакіраваны трафік

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

Калі палітыка абараняе 10.20.0.0/24, а ASA бярэ крыніцу са свайго знешняга адраса, пакет журнала альбо выходзіць адкрытым тэкстам да зборшчыка, да якога ён не можа дабрацца, альбо адкідваецца. Абодва вынікі з боку зборшчыка выглядаюць аднолькава. Тое ж разважанне датычыцца кіравальнага трафіку, таму management-access — асобнае праектнае рашэнне.

Якую крыніцу ASA ставіць у сетку

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

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

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

Супастаўце селектар з патокам журнала

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

Бок зборшчыка мае ўласныя патрабаванні: ACL, які дазваляе крыніцу ASA, зваротны маршрут і служба праслухоўвання на порце, які вы наладзілі. Транспарт тут таксама важны, бо журналізацыя TCP і TLS паводзіць сябе інакш, чым UDP на часткова заблакаваным шляху. Змяняйце па адным элеменце, інакш наступны захоп не скажа, якое змяненне мела значэнне.

Праверце на зборшчыку, затым запішыце крыніцу

Пацвердзіце, што паведамленне прыйшло, затым запішыце адрас крыніцы, які выкарыстаў ASA, селектар, які яго пранес, і ўзровень сур’ёзнасці, з якім вы тэставалі.

Гэты запіс ператварае наступнае змяненне ACL зборшчыка або праваку селектара ў двуххвілінную праверку замест паўторнага адкрыцця. Ён таксама дакументуе, які з двух патокаў калі-небудзь правяраўся, і менавіта гэтую частку большасць рэгламентаў апускае. Калі паведамленне ўсё яшчэ не прыходзіць, часова панізьце парог сур’ёзнасці і праверце адзін пункт прызначэння.

Даведка FAQ па журналізацыі ASA ад Cisco дакументуе выпадак з знешняй крыніцай, які патрабуе адпаведнага вызначэння абароненага трафіку, а яго прыклад з унутранай крыніцай уключае і хаст журнала ўнутры, і management-access унутры. Разглядайце дакументаваную камбінацыю і кантэкст праграмнага забеспячэння разам, а не здагадвайцеся, што адзін скапіяваны радок падыходзіць да любой канфігурацыі.

Тунель, які нясе трафік LAN, — гэта не тунель, які нясе ўласны голас міжсеткавага экрана.