OVPN такой-же тупой как Netwatch Или не совсем ?

[grifin.ru]

Как удалось недавно выяснить Netwatch, когда рожает проверочный пакет, ставит ему Source address просто посмотрев в таблицу MAIN, и ему глубоко наплевать что этот пакет будет, в силу имеющихся RULE маршрутизироваться правилами совсем из другой таблицы. В итоге пакет улетает к провайдеру 2 с IP провайдера 1 и, в лучшем случае, если у провайдера 1 проблемы - пакет не сможет вернуться. Т.е. Netwatch Покажет падение оператора 2, даже если упал оператор 1.

Куча костылей с src-nat помогла решить задачу, но я тут смотрю и у меня такое ощущение что одним только Netwatch'ем проблема не ограничивается.

Если в альтернативной таблице (не MAIN) прописать маршруты к разным OVPN серверам не получается-ли тоже самое ? Не будет ли VPN сервер слать трафик на не тот IP ?

[nkusnetsov]

7 часов назад, grifin.ru сказал:

Если в альтернативной таблице (не MAIN)

Переведите с английского слово "MAIN". Подумайте хорошенько. Она не может быть "альтернативной". В данном случае Вы бредите.

Очевидно, Вы неправильно представляете себе механизм работы маршрутизации в Linux. Linux-based маршрутизаторы для внутренних целей, для пакетов порожденных системой используют именно таблицу MAIN.

 

[LostSoul]

3 часа назад, nkusnetsov сказал:

Переведите с английского слово "MAIN". Подумайте хорошенько. Она не может быть "альтернативной". В данном случае Вы бредите.

Очевидно, Вы неправильно представляете себе механизм работы маршрутизации в Linux. Linux-based маршрутизаторы для внутренних целей, для пакетов порожденных системой используют именно таблицу MAIN.

 

Вы может быть представляете и лучше, но обьяснения ваши неточны.

Какой у пакета будет src адрес у локально порожденного пакета определяется в первую очередь запросом bind приложения, если там выставлено 0.0.0.0 , то путем поиска маршрута в таблице main наиболее длинного маршрута к целевому хосту и анализируется указан ли конкретный pref_src для данного маршрута, если указан то выбирается он.

Если pref_src не указан , далее определяется ближайший из локальных IP системы,  с учетом выставленных для них scope. ( ищится ближайший  по адресному пространству )

Потом уже принимается решение куда направить пакет на выход, в том числе поиск rule , таблиц и.т.п. , а потом какие трансформации на выходе с ним произвести.  ( snat и.т.п. )

 

 

 

[nkusnetsov]

1 час назад, LostSoul сказал:

если там выставлено 0.0.0.0 , то путем поиска маршрута в таблице main наиболее длинного маршрута к целевому хосту

И этот человек говорит о неточности у кого-то. Вы хотя бы переводите на русский корректно. От "наиболее длинного" маршрута весьма повеселился. Различайте на письме пожалуйста длинну маршрута и длинну префикса (маски).

В остальном согласен.

Но спрашивающий страдает от неполноты таблицы main. Может теперь чуть начнет разбираться.

[grifin.ru]

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'а, который рекомендует использовать несколько микротиков )

[LostSoul]

1 час назад, nkusnetsov сказал:

Вы хотя бы переводите на русский корректно.

Давайте оставлю без перевода.  more specific route

 

[myth]

более узкий маршрут

[LostSoul]

9 часов назад, myth сказал:

более узкий маршрут

вероятно по русски будет ближе всё таки "наиболее точный/детальный" маршрут.