ᴋ🚀
faq123
А в юсб устройствах есть?
это терминал в гипервизоре
Size: a a a
2020 May 20
W
Я думаю дело в цветах, они мило сочетаются
А ты знаток!😂
f
ᴋɪʀɪʟʟ 🚀
это терминал в гипервизоре
Пробросил же?
Sf
Мне еще зеленый нравится, но в росатом пока не хочу
f
ᴋɪʀɪʟʟ 🚀
это терминал в гипервизоре
Мне скоро для бухгалтери тоже токены пробрасыват)
FL
из-за микротика такая же проблема. В принципе, твой workaround с алиасом вполне годный, раз невозможно ничего поменять
еще раз на пальцах можете обьяснить, в чем бяда, или статью, где на пальцах разжуют почему ЭТО не реализовать именно ТАК КАК я хочу.
f
еще раз на пальцах можете обьяснить, в чем бяда, или статью, где на пальцах разжуют почему ЭТО не реализовать именно ТАК КАК я хочу.
Объясни ещё раз, как ты хочешь и что)
PZ
еще раз на пальцах можете обьяснить, в чем бяда, или статью, где на пальцах разжуют почему ЭТО не реализовать именно ТАК КАК я хочу.
в GRE просто нет поля "номер порта". у ядра не получится различать несколько GRE-соединений между одними и теми же внешними IP.
но есть call id.
в линуксе и микротике это работает точно. об этом комментарии в куске кода ядра линукса, который я привел.
как в bsd - не известно.
но есть call id.
в линуксе и микротике это работает точно. об этом комментарии в куске кода ядра линукса, который я привел.
как в bsd - не известно.
KF
посоветуйте норм коммутатор в стойку, гигабитный и шоб оптикой связать парочку таких
IO
еще раз на пальцах можете обьяснить, в чем бяда, или статью, где на пальцах разжуют почему ЭТО не реализовать именно ТАК КАК я хочу.
в случае TCP соединения на каждой стороне создаётся сокет - пара IP:port.
В случае pptp соединения, траффик идёт по протоколу GRE (это на том же уровне, что TCP), а он не имеет сущности ПОРТ.
ПОэтому от двух разных клиентов (которые за шлюзом) на ВПН сервер приходят два разных коннекта, но с одного IP (адрес шлюза) по протоколу GRE. Различить их ВПН-сервер не может.
И соответственно шлюз, получая обратные пакеты от сервера, тоже не может понять, какому клиенту они предназначены.
В случае pptp соединения, траффик идёт по протоколу GRE (это на том же уровне, что TCP), а он не имеет сущности ПОРТ.
ПОэтому от двух разных клиентов (которые за шлюзом) на ВПН сервер приходят два разных коннекта, но с одного IP (адрес шлюза) по протоколу GRE. Различить их ВПН-сервер не может.
И соответственно шлюз, получая обратные пакеты от сервера, тоже не может понять, какому клиенту они предназначены.
IO
в GRE просто нет поля "номер порта". у ядра не получится различать несколько GRE-соединений между одними и теми же внешними IP.
но есть call id.
в линуксе и микротике это работает точно. об этом комментарии в куске кода ядра линукса, который я привел.
как в bsd - не известно.
но есть call id.
в линуксе и микротике это работает точно. об этом комментарии в куске кода ядра линукса, который я привел.
как в bsd - не известно.
сейчас специально проверю с микротом. Но всегда считалось, что это не работает
FL
хочу через freebsd (IPFW+IPNAT) прокинуть 2 pptp соединения через 1 IP.
map em0(интерфейс на шлюзе 172.17.17.15.253\32) from 172.17.12.0.0/22 to 172.17.12.17/32 -> 172.17.15.253/32
Что бы любой из подсети 172.17.12.0/22 мог поднять pptp на сервере 172.17.12.17 (freebsd+mpd5)
map em0(интерфейс на шлюзе 172.17.17.15.253\32) from 172.17.12.0.0/22 to 172.17.12.17/32 -> 172.17.15.253/32
Что бы любой из подсети 172.17.12.0/22 мог поднять pptp на сервере 172.17.12.17 (freebsd+mpd5)
PZ
сейчас специально проверю с микротом. Но всегда считалось, что это не работает
мы это обсуждали в прошлом году в чате с микротами и ты поленился дочитать. почти у всех работало
FL
в случае TCP соединения на каждой стороне создаётся сокет - пара IP:port.
В случае pptp соединения, траффик идёт по протоколу GRE (это на том же уровне, что TCP), а он не имеет сущности ПОРТ.
ПОэтому от двух разных клиентов (которые за шлюзом) на ВПН сервер приходят два разных коннекта, но с одного IP (адрес шлюза) по протоколу GRE. Различить их ВПН-сервер не может.
И соответственно шлюз, получая обратные пакеты от сервера, тоже не может понять, какому клиенту они предназначены.
В случае pptp соединения, траффик идёт по протоколу GRE (это на том же уровне, что TCP), а он не имеет сущности ПОРТ.
ПОэтому от двух разных клиентов (которые за шлюзом) на ВПН сервер приходят два разных коннекта, но с одного IP (адрес шлюза) по протоколу GRE. Различить их ВПН-сервер не может.
И соответственно шлюз, получая обратные пакеты от сервера, тоже не может понять, какому клиенту они предназначены.
+ спасибо
FL
в GRE просто нет поля "номер порта". у ядра не получится различать несколько GRE-соединений между одними и теми же внешними IP.
но есть call id.
в линуксе и микротике это работает точно. об этом комментарии в куске кода ядра линукса, который я привел.
как в bsd - не известно.
но есть call id.
в линуксе и микротике это работает точно. об этом комментарии в куске кода ядра линукса, который я привел.
как в bsd - не известно.
+ спасибо вам тоже
FL
в GRE просто нет поля "номер порта". у ядра не получится различать несколько GRE-соединений между одними и теми же внешними IP.
но есть call id.
в линуксе и микротике это работает точно. об этом комментарии в куске кода ядра линукса, который я привел.
как в bsd - не известно.
но есть call id.
в линуксе и микротике это работает точно. об этом комментарии в куске кода ядра линукса, который я привел.
как в bsd - не известно.
Можно ли из ваших слов сделать вывод, что если буду использовать линукс (debian,centos) удастся побороть мою проблему?
PZ
Можно ли из ваших слов сделать вывод, что если буду использовать линукс (debian,centos) удастся побороть мою проблему?
наверняка, да. но раз у людей разные отзывы об этом сценарии, наверное все-таки иногда не работает по невыясненным причинам.
FL
уже что-то :)
пойду на debian, спасибо еще раз
пойду на debian, спасибо еще раз
PZ
да модем бытовой надо притащить и быстро протестить
f
посоветуйте норм коммутатор в стойку, гигабитный и шоб оптикой связать парочку таких
Циско sg250-50-k9-eu