tunsafe.com/support
Q: Can I route all network traffic throgh TunSafe?
A: Yes, TunSafe configures the computer to route all traffic through the peer with AllowedIPs=0.0.0.0/0
т.е. на клиенте нужно прописать AllowedIPs=0.0.0.0/0 и убедиться, что маршрут по-умолчанию — это интерфейс WireGuard, когда он включен.
На сервере нужно не забыть включить IPv4 forwarding и masquerade в iptables, все это описано в мануалах.
Насчет производительности не скажу, теоретически парсеру меньше работы + появляется возможность кешировать результаты парсинга.
В документации указано, что главный плюс — это безопасность:
The primary advantage of PQexecParams over PQexec is that parameter values can be separated from the command string, thus avoiding the need for tedious and error-prone quoting and escaping.… has some usefulness as an extra defense against SQL-injection attacks.
А чтобы все висло из-за значений… ну не знаю. Это постараться надо :)
На досуге надо глянуть, интересно как отобразится такой запрос в pg_stat_activity — с уже конкретными значениями или нет.
Хехе, это уже не мой вопрос. Моим решением было бы очевидное — все переписать заново самостоятельно (по деньгам бы дешевле вышло чем поддержка+обновления до актуальных версий). Но бизнес к такому не готов :)
Вариантов решения всегда много… Наверное, тогда просто опыта не хватило это сделать, хотя сейчас действительно это кажется верным вариантом. Но сейчас уже не хочется этим заниматься, т.к. все это в куче мест уже в эксплуатации. Поэтому и ищутся быстрые костыли :)
Потому что костыль — мое второе имя версия используемого ПО уже не поддерживается разработчиком, даже за деньги. Да и не будет он ради нас воротить партиционирование, т.к. это у него не самый важный продукт. Но к его чести, советы как лучше сделать партиционирование он все-таки дает, правда за деньги :)
Киньте ссыль в личку, если можно.
У ruvds можно взять VPS с 0,5Гб RAM за 130р/мес, если за год оплатить — то 104р/мес. Для РФ вполне… Если б он еще только нормально работал… Для большинства задач его хватало бы (ну без СУБД конечно).
Не вопрос. Я собственно уже перевел все сервисы на хецнер. Но если почините — возможно, что-то переплывет обратно.
Ну и по поводу поддержки — outsource и экономия это здорово.
Но для сравнения когда например GoDaddy списал с меня автоматом денег за домен, про который я забыл — они по звонку в течение 10 минут все отменили и вернули деньги в полном размере (хотя домен уже неделю проработал).
В похожей ситуации у вас: обрадовался низкому RTT, оплатил хостинг на год вперед (скидка же, скупой платит дважды). Далее захотел отменить…
На первое письмо ответили быстро, спросили как хочу вернуть деньги на счет. Ответил что другой хостинг в зачет не нужен, верните на карту. Следующий ответ почему-то пришлось ждать 4 рабочих (!!!) дня. Ну и ответ «мы удержим 10% согласно договора, который никто не читает»…
Когда уже бизнес поймет, что хорошо расстаться с клиентом — зачастую значит его вернуть.
Услугами GoDaddy я воспользовался снова. А вашими — даже не знаю…
Это не камень в ваш конкретный огород, а так — мысли вслух…
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=15 ttl=57 time=5.51 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=16 ttl=57 time=4.54 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=17 ttl=57 time=6.22 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=18 ttl=57 time=5.82 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=19 ttl=57 time=5.82 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=20 ttl=57 time=5.60 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=21 ttl=57 time=41.9 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=22 ttl=57 time=5.26 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=23 ttl=57 time=30.3 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=24 ttl=57 time=40.9 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=25 ttl=57 time=29.5 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=26 ttl=57 time=16.1 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=27 ttl=57 time=4.53 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=28 ttl=57 time=36.7 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=29 ttl=57 time=15.0 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=30 ttl=57 time=28.0 ms
Какие-то постоянные пертурбации…
Трассировка раз
traceroute to MY_HOST_ADDR (MY_IP_ADDR), 30 hops max, 60 byte packets
1 router (192.168.1.1) 0.531 ms 0.518 ms 0.516 ms
2 тут мой провайдер
3 тут мой провайдер
4 zn-comcor-network-gw2.zhukovsky.net (87.245.160.169) 3.310 ms 3.408 ms 3.464 ms
5 62.117.100.153 (62.117.100.153) 4.553 ms 4.594 ms *
6 * * *
7 * * *
8 * * *
9 * * *
10 * ptr.5x00.ru (MY_IP_ADDR) 5.443 ms 5.359 ms
Трассировка два
traceroute to MY_HOST_ADDR (MY_IP_ADDR), 30 hops max, 60 byte packets
1 router (192.168.1.1) 0.590 ms 0.580 ms 0.580 ms
2 тут мой провайдер
3 тут мой провайдер
4 zn-comcor-network-gw2.zhukovsky.net (87.245.160.169) 3.755 ms 3.794 ms 3.794 ms
5 62.117.100.153 (62.117.100.153) 5.986 ms 6.024 ms 6.026 ms
6 82.138.46.58 (82.138.46.58) 3.797 ms 2.984 ms 2.930 ms
7 * * *
8 ptr.5x00.ru (MY_IP_ADDR) 4.383 ms 6.321 ms 6.323 ms
Полагаю проблема может быть и в Комкоре…
Номер сервера RU185931.
P.S. кстати так и не нашел где reverse-запись DNS прописать для сервера…
Тарифы действительно не самые плохие для РФ. Но виртуализация очень тормознутая. Взял самую слабую VPSку на тест. Брал из-за RTT в 7мс. После некоторого времени RTT стал обычным, около 30мс… Часто соединения с сервером (ощущение что сам сервер) подвисают на несколько секунд… Вобщем, по сравнению с тем же хецнером (где самая слабая VPS в 2-3 раза богаче) — тоска и печаль… Закон Яровой в действии?...)
Проблема в том, что этот определенный STUN-ом внешний порт будет действителен только для обмена между клиентом и STUN-сервером. Когда это все пойдет сигнальному серверу или противоположному пиру, внешний порт будет уже другим. Обычно же сейчас в conntrack сессия идентифицируется 4 значениями — src IP+port, dst IP+port…
Более того, в больших NAT-ах и внешний IP также может выдаваться разный, из пула…
> Тогда клиенты будут знать друг о друге с правильными IP-адресами, и смогут установить P2P соединение.
= не очень понятно, как все-таки предлагается установить р2р соединение между двумя клиентами за NAT (без ретранслятора). Ну знаете вы их внешние IP-адреса, дальше что? Внешние порты, которые будут назначены при NAT, заранее все равно неизвестны.
1. Можно сделать слушающий Viewer, наподобие VNC Listening Viewer. Т.е. когда клиент и сервер меняются ролями, и комп-сервер обращается к клиенту. А клиент как правило админ, может иметь белый IP и в состоянии прокинуть к себе порт извне.
2. Также готов помочь в создании proxy и directory сервера. Могу написать на Qt, чтобы можно было ставить на приватные машины под Linux/Win. Больших нагрузок, как уже выше писалось, не выдержит, но как минимум несколько десятков, а то и сотню сессий потянет думаю.
Идея такова:
2.1 каждому инстансу (клиенту или серверу) прописывается учетка на proxy-сервере вида username@domain.com (или username@1.2.3.4, или username@1.2.3.4:tcp-port).
2.2. каждый инстанс держит простое контрольное соединение с proxy-сервером под своей учеткой.
2.3. proxy-сервера можно связывать между собой отдельными учетками (т.е. proxy-сервер foo может быть связан с proxy-сервером bar и знать как прокидывать к нему соединения). Таким образом можно административно делить пользователей и нагрузку на proxy-сервера одной организации/сети.
2.4. при попытке обращения одного инстанса к другому (по адресу вида username@domain.com) proxy-сервер определяет состояние username (даже если он в другом, связанном домене) и его возможности (версию ПО, наличие и тип NAT, и т.д.).
2.5. соответственно, если либо вызывающий, либо вызываемый инстанс не за NAT, значит им сообщаются данные для соединения и они устанавливают прямую связь. Таким образом даже динамические IP-адреса инстансов перестают быть проблемой.
2.6. если оба инстанса за NAT — тогда соединение прокидывается через proxy (здесь он выступает тупо как socks-прокси, т.е. внутри между инстансами должно быть сквозное шифрование). Также можно сделать возможность выполнять в этом случае различные скрипты (например, для динамического конфигурирования firewall и открытия портов).
Какие-то такие мысли пока…
Публичные серверы тоже можно сделать, правда для этого действительно Qt не особо подойдет. И load balancer-ы все равно нужно будет покупать.
Это не проблема tcp, это проблема любогл vpn, каким бы он ни был, tcp, udp, ipsec, gre — все они добавляют заголовки и уменьшают mtu.
Q: Can I route all network traffic throgh TunSafe?
A: Yes, TunSafe configures the computer to route all traffic through the peer with AllowedIPs=0.0.0.0/0
т.е. на клиенте нужно прописать AllowedIPs=0.0.0.0/0 и убедиться, что маршрут по-умолчанию — это интерфейс WireGuard, когда он включен.
На сервере нужно не забыть включить IPv4 forwarding и masquerade в iptables, все это описано в мануалах.
В документации указано, что главный плюс — это безопасность:
А чтобы все висло из-за значений… ну не знаю. Это постараться надо :)
На досуге надо глянуть, интересно как отобразится такой запрос в pg_stat_activity — с уже конкретными значениями или нет.
костыль — мое второе имяверсия используемого ПО уже не поддерживается разработчиком, даже за деньги. Да и не будет он ради нас воротить партиционирование, т.к. это у него не самый важный продукт. Но к его чести, советы как лучше сделать партиционирование он все-таки дает, правда за деньги :)У ruvds можно взять VPS с 0,5Гб RAM за 130р/мес, если за год оплатить — то 104р/мес. Для РФ вполне… Если б он еще только нормально работал… Для большинства задач его хватало бы (ну без СУБД конечно).
Ну и по поводу поддержки — outsource и экономия это здорово.
Но для сравнения когда например GoDaddy списал с меня автоматом денег за домен, про который я забыл — они по звонку в течение 10 минут все отменили и вернули деньги в полном размере (хотя домен уже неделю проработал).
В похожей ситуации у вас: обрадовался низкому RTT, оплатил хостинг на год вперед (скидка же, скупой платит дважды). Далее захотел отменить…
На первое письмо ответили быстро, спросили как хочу вернуть деньги на счет. Ответил что другой хостинг в зачет не нужен, верните на карту. Следующий ответ почему-то пришлось ждать 4 рабочих (!!!) дня. Ну и ответ «мы удержим 10% согласно договора, который никто не читает»…
Когда уже бизнес поймет, что хорошо расстаться с клиентом — зачастую значит его вернуть.
Услугами GoDaddy я воспользовался снова. А вашими — даже не знаю…
Это не камень в ваш конкретный огород, а так — мысли вслух…
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=15 ttl=57 time=5.51 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=16 ttl=57 time=4.54 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=17 ttl=57 time=6.22 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=18 ttl=57 time=5.82 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=19 ttl=57 time=5.82 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=20 ttl=57 time=5.60 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=21 ttl=57 time=41.9 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=22 ttl=57 time=5.26 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=23 ttl=57 time=30.3 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=24 ttl=57 time=40.9 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=25 ttl=57 time=29.5 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=26 ttl=57 time=16.1 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=27 ttl=57 time=4.53 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=28 ttl=57 time=36.7 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=29 ttl=57 time=15.0 ms
64 bytes from ptr.5x00.ru (MY_IP_ADDR): icmp_req=30 ttl=57 time=28.0 ms
Какие-то постоянные пертурбации…
traceroute to MY_HOST_ADDR (MY_IP_ADDR), 30 hops max, 60 byte packets
1 router (192.168.1.1) 0.531 ms 0.518 ms 0.516 ms
2 тут мой провайдер
3 тут мой провайдер
4 zn-comcor-network-gw2.zhukovsky.net (87.245.160.169) 3.310 ms 3.408 ms 3.464 ms
5 62.117.100.153 (62.117.100.153) 4.553 ms 4.594 ms *
6 * * *
7 * * *
8 * * *
9 * * *
10 * ptr.5x00.ru (MY_IP_ADDR) 5.443 ms 5.359 ms
traceroute to MY_HOST_ADDR (MY_IP_ADDR), 30 hops max, 60 byte packets
1 router (192.168.1.1) 0.590 ms 0.580 ms 0.580 ms
2 тут мой провайдер
3 тут мой провайдер
4 zn-comcor-network-gw2.zhukovsky.net (87.245.160.169) 3.755 ms 3.794 ms 3.794 ms
5 62.117.100.153 (62.117.100.153) 5.986 ms 6.024 ms 6.026 ms
6 82.138.46.58 (82.138.46.58) 3.797 ms 2.984 ms 2.930 ms
7 * * *
8 ptr.5x00.ru (MY_IP_ADDR) 4.383 ms 6.321 ms 6.323 ms
Полагаю проблема может быть и в Комкоре…
Номер сервера RU185931.
P.S. кстати так и не нашел где reverse-запись DNS прописать для сервера…
Более того, в больших NAT-ах и внешний IP также может выдаваться разный, из пула…
= не очень понятно, как все-таки предлагается установить р2р соединение между двумя клиентами за NAT (без ретранслятора). Ну знаете вы их внешние IP-адреса, дальше что? Внешние порты, которые будут назначены при NAT, заранее все равно неизвестны.
1. Можно сделать слушающий Viewer, наподобие VNC Listening Viewer. Т.е. когда клиент и сервер меняются ролями, и комп-сервер обращается к клиенту. А клиент как правило админ, может иметь белый IP и в состоянии прокинуть к себе порт извне.
2. Также готов помочь в создании proxy и directory сервера. Могу написать на Qt, чтобы можно было ставить на приватные машины под Linux/Win. Больших нагрузок, как уже выше писалось, не выдержит, но как минимум несколько десятков, а то и сотню сессий потянет думаю.
Идея такова:
2.1 каждому инстансу (клиенту или серверу) прописывается учетка на proxy-сервере вида username@domain.com (или username@1.2.3.4, или username@1.2.3.4:tcp-port).
2.2. каждый инстанс держит простое контрольное соединение с proxy-сервером под своей учеткой.
2.3. proxy-сервера можно связывать между собой отдельными учетками (т.е. proxy-сервер foo может быть связан с proxy-сервером bar и знать как прокидывать к нему соединения). Таким образом можно административно делить пользователей и нагрузку на proxy-сервера одной организации/сети.
2.4. при попытке обращения одного инстанса к другому (по адресу вида username@domain.com) proxy-сервер определяет состояние username (даже если он в другом, связанном домене) и его возможности (версию ПО, наличие и тип NAT, и т.д.).
2.5. соответственно, если либо вызывающий, либо вызываемый инстанс не за NAT, значит им сообщаются данные для соединения и они устанавливают прямую связь. Таким образом даже динамические IP-адреса инстансов перестают быть проблемой.
2.6. если оба инстанса за NAT — тогда соединение прокидывается через proxy (здесь он выступает тупо как socks-прокси, т.е. внутри между инстансами должно быть сквозное шифрование). Также можно сделать возможность выполнять в этом случае различные скрипты (например, для динамического конфигурирования firewall и открытия портов).
Какие-то такие мысли пока…
Публичные серверы тоже можно сделать, правда для этого действительно Qt не особо подойдет. И load balancer-ы все равно нужно будет покупать.