NAT over iBGP через туннели с MPLS TE, почему пинги идут а веб не открывается?
Добрый день Дамы и Господа! Очень сложный вопрос над которым бились я и еще два специалиста куда круче меня. Но к сожалению карантин и доступа у них сейчас нет(дать не можем).
И так представьте схему, два маршрутизатора, между которыми GRE туннели с MPLS+TE, поднят BGP (as200, т.е. IBGP)
За первым сеть 192.168.38.0/24
За вторым 192.168.113.2/30, nat outside. Веб сервер куда мы хотим "достучаться" 192.168.13.3 он находится за шлюзом 192.168.113.1 который НАТится соответственно.
192.168.13.3 доступен через 192.168.113.1 Так же за вторым есть другая сеть 10.32.0.0/24 с неё 192.168.13.3 по ВЕБу открывается! а со 192.168.38.0/24 НЕ открывается
и так, при попытке открыть узел 192.168.13.3 с сети 192.168.38.0/24 вижу что НАТ срабатывает
sh ip nat translations | i 192.168.13.3
все ОК! Соответственно пинги идут идеальные со ВСЕХ узлов как 192.168.38.0/24 так и с 10.32.0.0/24
Игрался с MTU и ip tcp adjust-mss, ничего не помогло
Подскажите куда копать? Очень специфичная проблема, но возможно кто-то сталкивался?
Буду ждать вопросов, полностью конфиг дать не могу к сожалению, но частями что надо конечно скину.
Я бы начал с определения места, где теряются пакеты. Проверить весь путь установления TCP соединения. Например, вы можете на 192.168.13.3 запустить Wireshark или tcpdump и убедиться, что SYN пакет на 80 порт приходит?
(не разбираюсь в BGP, просто мимокрокодил)
Попробуйте проверить ping google.com
Если резолва не будет, то могу предположить что ваши DNS сервера не резолвяться. Если выход только на локальный веб, то можно поставить доменное имя на айпишник и посмотреть резолвнит ли его с целевого устройства чтобы подтвердить что у сетей одно доменное пространство. Возможно еще настройка iptables нужна, т.к пинги идут как icmp пакеты в отличии от веба.
там нет глобалки, host to host идет соединение, без использования DNS, по ip адресу. веб сервер находится за НАТом и видит все входящие к нему соединения из моей сети как от 192.168.113.2, ему по сути плевать что дальше за ним, от отвечает ему, далее для него узлов нет
Гарри, смысл в том, что пакет TCP не может найти обратный путь для установки handshake'а: нужно искать причину именно здесь. Сниффер подключайте на разных сегментах и анализируйте пакетный обмен.
Как выяснилось NAT не срабатывает на tcp трафик, с icmp все ок.
На вебе коллеги запустили снифер увидели что приходит пакет от 192.168.38.xx, как такое возможно?
Вот access-list NAT'a
permit ip 192.168.38.0 0.0.0.255 host 192.168.13.3
deny ip any any
как же так? тут ведь не указано так, если бы так было то логично.
permit icmp 192.168.38.0 0.0.0.255 host 192.168.13.3
deny tcp 192.168.38.0 0.0.0.255 host 192.168.13.3
deny ip any any
Простой
