Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Вы можете установить OpenSSH на системе с Windows установкой одной галочки в списке «компонентов», а потом использовать этот SSH-сервер как SOCKS-прокси с помощью либо обычного ssh-клиента, либо многопоточной быстродейственной альтернативы.
А зачем?
Несмотря на то, что оверхед у пакетной маршрутизации меньше, чем у проксирования соединений, практическая скорость у прокси в условиях реальной сети выше по весьма банальной причине: TCP-ретрансмиты при потерях происходят независимо на двух разных участках — между прокси и клиентом и между прокси и целевым узлом.
Если всё что требуется — это гонять весь трафик через удалённый сервер, то проксирование как технология — самое то. Ну а в качестве узла для доступа внутрь частной сети Windows попросту не самый удачный выбор именно с технологической точки зрения.
Несмотря на то, что оверхед у пакетной маршрутизации меньше, чем у проксирования соединений, практическая скорость у прокси в условиях реальной сети выше по весьма банальной причине: TCP-ретрансмиты при потерях происходят независимо на двух разных участках — между прокси и клиентом и между прокси и целевым узлом.
Если всё что требуется — это гонять весь трафик через удалённый сервер, то проксирование как технология — самое то. Ну а в качестве узла для доступа внутрь частной сети Windows попросту не самый удачный выбор именно с технологической точки зрения.
VPS использую для разных целей, например: Apache2, Nginx, Mysql, PHP, Bind9, Postfix, Dovecot, OpenVPN и прочее… Всего по-немножку
Данное решение используется для подключения двух компьютеров каждый из которых находится за NATами, StrongSwon можно использовать поверх
Данное решение используется для подключения двух компьютеров каждый из которых находится за NATами, StrongSwon можно использовать поверх
Всем доброго дня! Пару комментариями выше человек посоветовал использовать SOCKS прокси, я к нему присоединяюсь. Самое нехорошая привычка это мешать Production с Testinng ом. В вашем случае у вас есть VPS, который в принципе видно используется в качестве вполне рабочего сервера, зачем вы открываете туннели на рабочей машине? Подумайте о безопасности, что если на другом конце у кого сидит зловредный скрипт, который обязательно воспользуется новой (для него) сетью.
Через tor без VPS: habr.com/ru/post/237019
Отличная идея! Может быть стоит развить её дальше и пробивать NAT с использованием публичных STUN-серверов, как это делают, например, браузеры для использования WebRTC?
Я думал об этом и думаю дальше, нужно понять как устроены пакеты которые нужно посылать на STUN и пакеты которые я получу в ответ
STUN дает только ответ на вопрос «какой у меня IP и порт», но от этого нет толку, если эта информация останется только у меня. Внешний сервер (ну или TOR hidden service, как уже предложили) нужен (в том числе при использовании WebRTC) как централизованная точка встречи для передачи этой информации другой стороне.
Думаю можно в роли диспетчера вместо выделенного сервера задекйствовать вебхостинг.
Я правильно понимаю, что если провайдер NATит с сохранением dst и фильтрацией по нему входящего трафика, то эта схема не заработает?
Да, в данном случае много чего зависит от того, как реализован NAT провайдера, но как правило используются динамические IP и тогда придется их всех заблокировать, что маловероятно… Torrent не блокируют, принцип похожий
Извиняюсь, с утра не полностью понял вопроса, да «если провайдер NATит с сохранением dst и фильтрацией по нему входящего трафика», но в этот момент узел шлет пакет навстречу удаленному узлу, и если там нет фильтрации, то уделенный узел изменит порт назначения и все будет хорошо, но вот если с двух сторон будет такая ситуация, то без посредника не обойтись. Я думаю об этом.
Можно и без VPS.
1) через любой STUN-сервер получаете ответ на вопрос «какой у меня внешние IP и порт»
2) через любой мессенджер через API, отправляете эту информацию второй стороне.
1) через любой STUN-сервер получаете ответ на вопрос «какой у меня внешние IP и порт»
2) через любой мессенджер через API, отправляете эту информацию второй стороне.
Как готовое решение можно использовать Tinc VPN.
Automatic full mesh routing
Regardless of how you set up the tinc daemons to connect to each other, VPN traffic is always (if possible) sent directly to the destination, without going through intermediate hops.
NAT traversal
As long as one node in the VPN allows incoming connections on a public IP address (even if it is a dynamic IP address), tinc will be able to do NAT traversal, allowing direct communication between peers.
Automatic full mesh routing
Regardless of how you set up the tinc daemons to connect to each other, VPN traffic is always (if possible) sent directly to the destination, without going through intermediate hops.
NAT traversal
As long as one node in the VPN allows incoming connections on a public IP address (even if it is a dynamic IP address), tinc will be able to do NAT traversal, allowing direct communication between peers.
какую только дичь люди не творят, лишь бы не юзать IPv6 ))))
(это, скорее, вопрос ко всяким провайдерам, которые до сих пор не дают нативный IPv6, или требуют за него у клиентов неадекватную денежку)
Сам говорю с позиции провайдера, который спокойно, неспеша, в рамках смены технологических циклов — ввел в эксплуатацию dual stack.
Ничего нет сложного и расходы на это не являются основными даже и близко
(это если вам будут говорить, что оборудование и софт обновить для поддержки ipv6 — это очень дорого). CG-NAT тоже дорого. А оборудование, в любом случае, обновляется каждые 5-7 лет. (Хотя бы потому, что трафики растут). И там уже везде давно есть ipv6.
И в клиентских роутерах и ОС тоже завезли.
На дворе 2020 год.
Серьезно — хватит бояццо и ненавидеть IPv6.
Я уже дошел до стадии принятия неизбежного )
P.S.
Только не надо начинать холивар, что ipv6 гомно и не безопасно…
IPv6 решает отлично задачу с нехваткой IPv4.
Да, возникают новые проблемы и задачи.
Это нормально.
Все решается соответствующими инструментами.
В частности, так называемая безопасность NAT (а на самом деле к безопасности имеет мало отношения) — «невидимость» домашних устройств «снаружи» для всего мира — в случае IPv6 аналогичный эффект легко решается statefull фаерволом (по дефолту запрет на инициацию соединений снаружи).
Но! При этом, при желании, что-то можно лего разрешить.
И вся эта дичь с NATом не нужна…
(это, скорее, вопрос ко всяким провайдерам, которые до сих пор не дают нативный IPv6, или требуют за него у клиентов неадекватную денежку)
Сам говорю с позиции провайдера, который спокойно, неспеша, в рамках смены технологических циклов — ввел в эксплуатацию dual stack.
Ничего нет сложного и расходы на это не являются основными даже и близко
(это если вам будут говорить, что оборудование и софт обновить для поддержки ipv6 — это очень дорого). CG-NAT тоже дорого. А оборудование, в любом случае, обновляется каждые 5-7 лет. (Хотя бы потому, что трафики растут). И там уже везде давно есть ipv6.
И в клиентских роутерах и ОС тоже завезли.
На дворе 2020 год.
Серьезно — хватит бояццо и ненавидеть IPv6.
Я уже дошел до стадии принятия неизбежного )
P.S.
Только не надо начинать холивар, что ipv6 гомно и не безопасно…
IPv6 решает отлично задачу с нехваткой IPv4.
Да, возникают новые проблемы и задачи.
Это нормально.
Все решается соответствующими инструментами.
В частности, так называемая безопасность NAT (а на самом деле к безопасности имеет мало отношения) — «невидимость» домашних устройств «снаружи» для всего мира — в случае IPv6 аналогичный эффект легко решается statefull фаерволом (по дефолту запрет на инициацию соединений снаружи).
Но! При этом, при желании, что-то можно лего разрешить.
И вся эта дичь с NATом не нужна…
Это вопрос не «скорее» а «в первую очередь» к провайдерам.
Ростелеком, сцк…
Ростелеком, сцк…
Да, согласен)
У этих мастодонтов очень длинные технологические циклы и инерционность.
Но, рано или поздно они это сделают.
В Беларуси вон — законодательно заставили давать IPv6 по требованию с 1 янв 2020
(Кстати, в Указе ничего не указали по поводу бесплатности — исполнители (провайдеры) могут установить заградительный ценник или требование установить определенные CPE за сотни нефти или довести процедуру до маразма)
У этих мастодонтов очень длинные технологические циклы и инерционность.
Но, рано или поздно они это сделают.
В Беларуси вон — законодательно заставили давать IPv6 по требованию с 1 янв 2020
(Кстати, в Указе ничего не указали по поводу бесплатности — исполнители (провайдеры) могут установить заградительный ценник или требование установить определенные CPE за сотни нефти или довести процедуру до маразма)
Я IPv6 не боюсь, у меня его просто нет. Ни дома, ни на работе
toxtun, toxvpn, yggdtasil, peervpn… tinc, множество вариаций на тему, и все требуют тем не менее что-то промежуточное…
Интересный (с точки зрения опыта) вариант велосипеда.
Обычно велосипед такой:
- есть внешний сервер, который в себе хранит данные об адресе и порте и "имени" клиентов, которые ждут соединение.
- Есть ещё один внешний сервер, который ждёт запроса (а запрос открывает порт), достает из него адрес и порт и отправляет эти данные обратно
- Клиент "регистрируется" на первом внешнем сервере, используя данные, полученные от второго
- Клиент запрашивает данные для соединения с другим клиентом, обращаясь на первый сервер
Первый и второй сервер могут быть на одной машине и даже на одном порту (но лучше разделить)
Могут дополнительно быть всякие авторизации, запросы подключений, запросы обновления адреса-порта, статистика и тп
Идея зачёт!
Жаль что мне знаний на хватает всё это понять и осмыслить.
Идея хорoшая, осмелюсь дать несколько советов:
— от tcpdump лучше отказаться в пользу http (php, python, nginx/lua/webdav2 etc...) т.к.он переводит интерфес в режим promisc
— диапазон доступных портов можно взять здесь /proc/sys/net/ipv4/ip_local_port_range
в итоге, задача сводится к тому, чтобы договорится о номерах портов и адресах, для этого можно использовать какой-нибудь pastebin и, как тут уже предлагалось, публичный stun-сервер.
— от tcpdump лучше отказаться в пользу http (php, python, nginx/lua/webdav2 etc...) т.к.он переводит интерфес в режим promisc
— диапазон доступных портов можно взять здесь /proc/sys/net/ipv4/ip_local_port_range
в итоге, задача сводится к тому, чтобы договорится о номерах портов и адресах, для этого можно использовать какой-нибудь pastebin и, как тут уже предлагалось, публичный stun-сервер.
Т.е., создание вручную чего-то такого, что умеет тот же tinc?
Radmin vpn в помощь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прямой VPN-туннель между двумя компьютерами находящимися за NAT провайдеров с использованием UDP hole punching