Выходим в открытый интернет или что делать, если ваш провайдер — редиска |GrakovNe - Пробуя, создавать лучшее

hello


Времени затрачено: 0,041 сек.
SQL запросов: 24
ОЗУ использовано: 4 MB
Войти как администратор

Выходим в открытый интернет или что делать, если ваш провайдер — редиска

Пинг! Пинг! Пи…

О своем радио, которое заменило мне локальные плееры во всем их многообразии, я не успел рассказать только, кажется, глухому. И то — не уверен. Так что, когда, одним прекрасным весенним утром, оно, в смысле радио, перестало работать — огорчился не только я, но и все остальные клиенты. Будем починять, решил я. И починил. И даже сейчас все расскажу

А чего случилось — то?

Если очень коротко — смена провайдера. И нет, я ни при чем. Просто живу я в хорошем таком частном доме и все нормальные ISP меня традиционно игнорируют. Зато, существует целая куча сомнительного качества контор, которые берут у этих самых нормальных ISP гигабитный канал и перепродают его мне. Ну, не только мне — всем желающим.

И если старый-добрый Эртелеком в качестве провайдера, считал всех абонентов корпоративными клиентами и выдавал каждому Настоящий Публичный IP Адрес, то новые и уже не очень добрые Omkc решили, что адресов на всех не хватит и завели всю подсеть на приватный диапазон.

А это — плохо. Потому что с этим приватным ip-шником моя малинка становится не только Крутой и Мощной, но и Очень Локальной. И достучаться до нее из внешней сети — не получится.

Будем исправлять? Будем

А как?

Будь у меня просто динамический IP, дело бы закончилось каким-нибудь No-Ip клиентом. А так, варианта всего два:

 Статичный IP адрес. Причем, не столько статичный, сколько — публичный. И решение, на самом деле — почти идеальное: арендуем у провайдера адрес, они перенастраивают свой DHCP и у вас наступает вселенское счастье.  Но когда я пришел в офис своего ISP и нагло спросил почем у них это счастье, они назвали мне сумму, примерно равную той, что я плачу за интернет-канал. А я жадный

VPN. Три буквы, куча магии, ага. Если коротко — штука, которая позволяет создать виртуальную локальную сеть, к которой можно подключиться откуда угодно, при условии, что сервер доступен из внешней сети. Значит — все, что нам надо, это разжиться по дешевке публично-доступным сервером и чуть-чуть постучать по клавиатуре.

Поехали!

А где взять сервер?

Вариантов масса. Самый простой — товарищ с постоянно работающей машинкой. Минус в том, что при обращении к моей малинке через VPN, весь проходящий трафик, будет проходить и через VPN — сервер. Поэтому, большинство моих товарищей смотрят на такую мою идею не очень радостно, а некоторые — даже через прицел. Не пойдет

Еще один вариант — арендовать что-нибудь в стойке ближайшего дата-центра. Быстро, качественно, эффективно. Дорого только, ага. Уж лучше статичный IP

И наконец то, чем мы воспользуемся — VPS. Виртуальная машинка, которая доступна из внешней сети, ни больше ни меньше. Стоит дешево, физического места не занимает, для пользователя от настоящего сервера не отличается ничем, а супер-производительность нам не особо-то и нужна… Берем!

А дальше?

Итак, сервер на Debian 8.0 с публичным адресом и доступ к нему по SSH у нас есть. Теперь, надо поднять на нем VPN. Вообще, правильные ребята обычно берут в этом случае супер-безопасный OpenVPN и развлекаются с его настройкой, но мне лень, поэтому, ставить и настраивать будем PPTP.

Для начала, стучимся по ssh к VPS, логинимся и ставим ppt — демона:

sudo apt-get install pptpd

После того, как система выкачала все пакеты и зависимости, отправляемся редактировать файл, который лежит /etc/pptpd.conf. Конфигурация, ага. И в ней нас интересуют всего две строчки:

localip 10.0.0.1

remoteip 10.0.0.100-200

localip — это адрес, который мы назначили себе любимому. Поскольку, сеть у нас не только виртуальная, но и частная, выбирать адрес для нее нужно из приватных диапазонов:

  • 10.0.0.0 — 10.255.255.255
  • 172.16.0.0 — 172.31.255.255
  • 192.168.0.0 — 192.168.255.255

remoteip — это диапазон адресов, которые будут назначаться клиентам сервера. Их выбирать можно как попало, лишь бы они оставались в одной подсети с сервером

Сохраняем файлик и идем редактировать другой: /etc/ppp/chap-secrets

В нем у нас хранятся креденшлы пользователей, которые хотят подключаться к серверу, причем хранятся в следующем формате:

<USERNAME> PPTPD <PASSWORD> <IP>

И если с логином и паролем все и так понятно, то ip — адрес можно задавать, и тогда он будет назначаться при каждом подключении, или не задавать, и тогда он будет назначаться случайно из пула свободных.

Второй вариант нам удобен, когда один и тот же клиент хочет одновременно подключаться к сети с нескольких устройств, но с одними и теми же данными.

Первый — для всяких там серверов, вроде нашей малинки.

Прописываем в файлике что-нибудь вроде:

grakovne pptpd password *
cloud pptpd password 10.0.0.100

и отправляем редактировать еще один файл конфигурации: /etc/ppp/pptpd-optios

Здесь нам нужно указать адреса DNS серверов на случай, если мы захотим (а мы захотим!) сходить из внутренней сети в настоящий интернет. Не  особо долго думая, прописываем сюда безотказные сервера гугла:

ms-dns 8.8.8.8
ms-dns 8.8.4.4

Сохраняемся и идем править последний на сегодня файлик: /etc/sysctl.conf

здесь добавляем или редактируем ровно одну строчку:

net.ipv4.ip_forward = 1

Она нам нужна для того, чтобы данные из VPN могли уходить наружу.

Сохраняемся и не забываем применить свежие правила:

sysctl -p

Готово! Теперь чуть-чуть магии Iptables, которая нам нужна, чтобы разные клиенты нашей VPN-ки могли напрямую общаться друг с другом:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE
iptables -I INPUT -s 10.0.0.0/8 -i ppp0 -j ACCEPT
iptables --append FORWARD --in-interface eth0 -j ACCEPT

Перезапускаем машину, поднимаем демона VPN (sudo service pptpd start) и получаем готовый VPN — сервер

Клиенты?

Если ваша клиентская машина под Windows, ваша жизнь сейчас станет немного радостнее: в настройках VPN указываем адрес сервера, логин, пароль и — подключаемся. Примерно так:

vpn

Готово, теперь у нас есть доступ к домашнему принтеру из любой точки земли, где вообще знают про Интернет

С машинами под Linux все немного сложнее

Для начала, нам нужен клиент:

 sudo apt-get install pptp-linux

Есть! Теперь, идем в /etc/ppp/peers и создаем там файлик, который может называться как угодно (например, grakovne_vpn) и пишем там:

pty "pptp 194.87.95.66 --nolaunchpppd"
name cloud
password my_password
remotename PPTP
require-mppe-128

Теперь можно подключаться к нашему серверу:

pppd call grakovne_vpn

По умолчанию, подключение запускается в фоне и в консоль ничего не выводит. Чтобы посмотреть лог и убедиться, что подключение удалось, цепляемся за системный лог:

 tail -f /var/log/syslog

Подключились? отлично! Теперь с сервера можно попробовать достучаться до клиента:

ping 10.0.0.100

Если приходит правильный эхо — ответ, все отлично. Здесь, кстати, нужно помнить, что на этом адресе у сети, в которой болтается наша VPS скорее всего уже что-то висит, поэтому пинговаться оно может даже в случае, если клиент не подключен

Все?

Вообще, да. В случае, если ваш сервер нужен только вам и вашему товарищу, которому вы заведете учетку VPN.

А если вы, как и я, хотите использовать VPN еще и как прокси-сервер, так, чтобы нужный трафик перебрасывался с публичного сервера на приватного клиента и обратно, а пользователь ничего не замечал, придется еще немного поработать с ip-tables:

Для каждого из портов, который вы хотите пробросить на клиента, пишем:

 iptables -t nat -A PREROUTING -p tcp --dport <porn_number> -j DNAT --to-destination 10.0.0.100

и проверяем прямо со своей машинки, которая уже ни к какой VPN не подключена. Работает? Отлично!

Восьмидесятый?

Да, с портом, который используется всеми публичными серверами — немного сложнее.

Разумеется, в общем случае, ничего не мешает точно так же, как и парой строк выше, пробросить http — порт на малинку, но в этом случае, находясь внутри VPN сети, совершенно логично ожидать, что весь http — трафик от любого клиента, будет заворачиваться на малинку. И никаких котиков на YouTube, ага.

Поэтому, найдем решение поизящнее: возвращаемся по ssh на нашу VPS и ставим там apache:

sudo apt install apache2

Теперь, ждем, пока оно стартанет и лезем в конфиг, который лежит: /etc/apache2/sites-enabled/000-default.conf

Здесь нам вместо всего-того-хлама-что-там-есть, нужно написать следующее:

<VirtualHost *:80>
 ProxyPreserveHost On
 ProxyPass / http://10.0.0.100:80/
 ProxyPassReverse / http://10.0.0.100:80/
</VirtualHost>

После чего, осталось только перезапустить апач:

sudo service apache reload

И попробовать постучаться на наш VPS — сервер по 80-му порту. Что, получили ответ с клиента? Отлично, а теперь я расскажу, что это было

И что?

Вообще, реверс — прокси. То есть, любой запрос на / нашего VPS-сервера, будет проксироваться на / нашего настоящего-домашнего-клиента. И обратно — тоже. При этом, любой другой адрес будет разворачиваться во внешнюю сеть, потому что Apache про него ничего не знает, а форвардинг ip — трафика в Интернет мы уже настроили. Классно, правда?

Фуф?

Фуф. Теперь у нас снова есть настоящий домашний сервер, доступный из любой точки мира. А у меня — еще и простаивающая VPS-ка, которую я сейчас нагружу Jenkins-ом, пусть себе собирает

Искренне Ваш, генерирующий гигабайты трафика вместо того, чтобы вставить в телефон флешку, GrakovNe



Комментарии закрыты.

vodafone tl yükleme kontör yükleme hamile giyim turkcell fatura alanya escort işbankası kredi kartı borç sorgulama kredi kartı ile elektrik faturası ödeme turkcell tl yükleme tl yükleme hgs yükleme emek serverler site ekle r57 shell antalya escort yapı kredi borç sorgulama finansbank borç sorgulama akbank borç sorgulama ogs yükleme enerjisa elektrik faturası ödeme clk akdeniz elektrik faturası ödeme elektrik faturası ödeme escort antalya hgs bakiye yükleme script indir fatura ödeme vodafone fatura ödeme hgs yükleme sex sohbet antalya escort