grifin.ru Posted February 7, 2018 Как удалось недавно выяснить Netwatch, когда рожает проверочный пакет, ставит ему Source address просто посмотрев в таблицу MAIN, и ему глубоко наплевать что этот пакет будет, в силу имеющихся RULE маршрутизироваться правилами совсем из другой таблицы. В итоге пакет улетает к провайдеру 2 с IP провайдера 1 и, в лучшем случае, если у провайдера 1 проблемы - пакет не сможет вернуться. Т.е. Netwatch Покажет падение оператора 2, даже если упал оператор 1. Куча костылей с src-nat помогла решить задачу, но я тут смотрю и у меня такое ощущение что одним только Netwatch'ем проблема не ограничивается. Если в альтернативной таблице (не MAIN) прописать маршруты к разным OVPN серверам не получается-ли тоже самое ? Не будет ли VPN сервер слать трафик на не тот IP ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nkusnetsov Posted February 8, 2018 7 часов назад, grifin.ru сказал: Если в альтернативной таблице (не MAIN) Переведите с английского слово "MAIN". Подумайте хорошенько. Она не может быть "альтернативной". В данном случае Вы бредите. Очевидно, Вы неправильно представляете себе механизм работы маршрутизации в Linux. Linux-based маршрутизаторы для внутренних целей, для пакетов порожденных системой используют именно таблицу MAIN. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
LostSoul Posted February 8, 2018 3 часа назад, nkusnetsov сказал: Переведите с английского слово "MAIN". Подумайте хорошенько. Она не может быть "альтернативной". В данном случае Вы бредите. Очевидно, Вы неправильно представляете себе механизм работы маршрутизации в Linux. Linux-based маршрутизаторы для внутренних целей, для пакетов порожденных системой используют именно таблицу MAIN. Вы может быть представляете и лучше, но обьяснения ваши неточны. Какой у пакета будет src адрес у локально порожденного пакета определяется в первую очередь запросом bind приложения, если там выставлено 0.0.0.0 , то путем поиска маршрута в таблице main наиболее длинного маршрута к целевому хосту и анализируется указан ли конкретный pref_src для данного маршрута, если указан то выбирается он. Если pref_src не указан , далее определяется ближайший из локальных IP системы, с учетом выставленных для них scope. ( ищится ближайший по адресному пространству ) Потом уже принимается решение куда направить пакет на выход, в том числе поиск rule , таблиц и.т.п. , а потом какие трансформации на выходе с ним произвести. ( snat и.т.п. ) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nkusnetsov Posted February 8, 2018 1 час назад, LostSoul сказал: если там выставлено 0.0.0.0 , то путем поиска маршрута в таблице main наиболее длинного маршрута к целевому хосту И этот человек говорит о неточности у кого-то. Вы хотя бы переводите на русский корректно. От "наиболее длинного" маршрута весьма повеселился. Различайте на письме пожалуйста длинну маршрута и длинну префикса (маски). В остальном согласен. Но спрашивающий страдает от неполноты таблицы main. Может теперь чуть начнет разбираться. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
grifin.ru Posted February 8, 2018 6 часов назад, nkusnetsov сказал: Переведите с английского слово "MAIN". Подумайте хорошенько. Она не может быть "альтернативной". В данном случае Вы бредите. Очевидно, Вы неправильно представляете себе механизм работы маршрутизации в Linux. Linux-based маршрутизаторы для внутренних целей, для пакетов порожденных системой используют именно таблицу MAIN. Это вы внимательно почитайте, там написано: "альтернативной таблице (не MAIN)", частицу "не" видите ? ;) 2 часа назад, LostSoul сказал: Вы может быть представляете и лучше, но обьяснения ваши неточны. Какой у пакета будет src адрес у локально порожденного пакета определяется в первую очередь запросом bind приложения, если там выставлено 0.0.0.0 , то путем поиска маршрута в таблице main наиболее длинного маршрута к целевому хосту и анализируется указан ли конкретный pref_src для данного маршрута, если указан то выбирается он. Если pref_src не указан , далее определяется ближайший из локальных IP системы, с учетом выставленных для них scope. ( ищится ближайший по адресному пространству ) Потом уже принимается решение куда направить пакет на выход, в том числе поиск rule , таблиц и.т.п. , а потом какие трансформации на выходе с ним произвести. ( snat и.т.п. ) Да, я уже разобрался. Все больше начинаю понимать SAAB'а, который рекомендует использовать несколько микротиков ) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
LostSoul Posted February 8, 2018 1 час назад, nkusnetsov сказал: Вы хотя бы переводите на русский корректно. Давайте оставлю без перевода. more specific route Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
myth Posted February 8, 2018 более узкий маршрут Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
LostSoul Posted February 9, 2018 9 часов назад, myth сказал: более узкий маршрут вероятно по русски будет ближе всё таки "наиболее точный/детальный" маршрут. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
