Я понял. Спасибо. Мне этого и нужно было, мол, «работать будет, у меня такая схема не работает».
Почему у меня не работает — буду разбираться.
Будем считать это ответом
Не, не пашет.
На ASA: Global 66.66.66.66 Local 172.16.1.10 Global 77.77.77.77 Local 192.168.2.50
Доступы:
на DMZ1 — ip host 172.16.1.10 any
на outside ip any host 77.77.77.77
packet-tracer packet-tracer input DMZ1 tcp 172.16.1.10 1000 77.77.77.77 1000 всё ок
packet-tracer packet-tracer input oitside tcp 66.66.66.66 1000 77.77.77.77 1000 всё ок
Маршруты на роутере который за outside ведут обратно на АСУ.
В общем всё вроде ок, но по факту трафик не ходит.
Не может ли ASA принимать это за какой-нить род спуффинга по своей хитрой логике? Может ли влиять на схему то, что у самой АСы на outside интерфейсе стоит 66.66.66.1 к примеру (в общем из того же диапазона)?
Извиняюсь, я видимо не правильно выразился в предыдущем комменте.
Packet-tracer показывает всё норм в описанной мною схеме.
Просто когда первый раз проверял в качестве Source указал 172.16.1.10, а в качестве Dest 66.66.66.66 (то есть тот адрес в который 172.16.1.10 собственно и транслируется), отсюда и Slowpath security checks failed.
Вообще, это была у меня самая первая идея — отказаться от NAT в этой схеме вообще.
Сеть строилась за долго до меня, и какими соображениями была вызвана потребность в NAT я не знаю. Сейчас переделать всё на роутинг будет очень сложно. Очевидно придётся строить костыли типа «тут роутинг, тут NAT»
На другой вопрос ответ — ну так нужно :)
Я понимаю что в идеале всё должно быть не так как есть, но работать приходится с тем что есть
Да, действительно радиус кривизны видимо выше нуля :(
Такая ошибка возникает когда я пытаюсь запустить пакет трейсер на эмуляцию доступа к «самому себе». Если в dest указывать другой ip, то всё ок
Дмитрий, в любом случае спасибо за помощь! Буду пробовать варианты
Хм, то есть получается что в описанной схеме всё должно работать по умолчанию? Единственное что нужно чтобы ASA однозначно знала что пакеты например с dest 66.66.66.66 нужно отправлять в сторону роутера. По идее в моём случае ASA итак отправит их в сторону роутера, ибо туда 0/0 ведёт.
Мне такая мысль даже в голову не приходила что всё и так должно работать :) Наверное потому что оно не работает. packet-tracer АСы дропает пакеты с Drop-reason: (sp-security-failed) Slowpath security checks failed
.
Железо другое может и есть, но аппаратные изменения в схеме включения не представляются возможным :(
Ну судя по прикреплённой информации не понятно каким образом
«С телефона (172.30.0.101) Я могу пропинговать любое устройство в сети».
Вот идёт пакет с телефона на адрес 192.168.1.34, и он пытается отправить его обратно на ip 172,30,0,101. Но о такой сети ему ничего не известно, поэтому он оптправляет на шлюз по умолчанию (192.168.1.1), который скорее всего тоже ничего не знает о сети 172.30.0.0 и отправляет пакет своему default gw, которым скорее всего является шлюз провайдера.
У вас точно с телефона телевизор, например, пингуется?
Если VPN, то процентов 80 у вас серый ip. Вообще уточнить это можно если посмотреть настройки самого крайнего к провайдеру устройства при поднятом VPN-е.
Здесь пожалуй даже три выхода:
— как я говорил, юзать сторонний прокси сервер, тогда для серверов Вконтакте будет казаться что вы приходите с ip-адреса этого прокси;
— купить услугу внешний ip-адрес. Думаю даже в Луганске должны предоставлять :) Да, возможно придётся переплатить;
— продолжать «долбить» провайдера. Но здесь я думаю всё зависит от его лояльности. Имхо — они не обязаны это делать. Но мы (когда я работал в мелком провайдере) обычно всегда шли на уступки клиентам в таких случаях.
