Предыстория:
В субботу пропал основной интернет от домашнего провайдера, теперь я выхожу в интернет через LTE-модем. Но на этом мои проблемы не закончились, дело в том, что мой Провайдер (NetBynet) дающий динамический WAN:IP, я его связал с домен четвертого уровня от Mikrotik и на домене ekzorchik.ru настроил CNAME-запись вида: remote.ekzorchik.ru. Далее либо через L2TP/IPSEC туннель могу подключаться к собственной серверной или через обычный проброс порта если нужно, но раз провайдер лежит, что получить доступ к моей серверной инфраструктуре я уже не могу. Выход реализовать задачу:
VPS:WAN_IP:Port Forward <-> (OpenVPN Server) <-> LTE: (OpenVPN Client) Mikrotik -> VM
Mikrotik RB2011UiAS-2HnD (v6.45.2) (роутер)HP MicroServer Gen8 (сервер для VM: Fog, OwnCloud, NAS, Wiki и т.д)Гипервизоры Proxmox (для теста и обкатки конфигураций)
Что есть в наличии и понадобится:
- Настройка связки
Mikrotik + USBмодем по заметке «Интернет через USB модем если отказал основной» - Куплена
VPSсистема и обновлена доUbuntu 18.04 Serverвот заметка « Как обновить Ubuntu Xenial до Bionic на CloudLITE” - На
VPSсистеме (далееsrv-vps) поднятOpenVPNтуннель между ее иMikrotikвот заметка «Настройка OpenVPN Server to Client Mikrotik» - Желание разобраться и добить в случае проблем задачу.
Решение!!!
Шаг №1: Нужно переделать конфигурационный файл на OpenVPN (srv-vpn) до вида:
root@srv-vpn:~# nano /etc/openvpn/server.conf port 1194 proto tcp dev tun0 ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key dh /etc/openvpn/dh2048.pem #for openvpn network server 10.8.0.0 255.255.255.0 push "route 172.200.200.0 255.255.255.0" route 172.200.200 255.255.255.0 10.8.0.1 ifconfig-pool-persist /var/log/openvpn/ipp.txt client-config-dir /etc/openvpn/ccd client-to-client keepalive 10 120 cipher AES-128-CBC auth SHA1 user nobody group nogroup persist-key persist-tun status /var/log/openvpn/openvpn-status.log log /var/log/openvpn/openvpn.log log-append /var/log/openvpn/openvpn.log verb 4 #explicit-exit-notify 1 #tls-auth ta.key 0 # This file is secret root@srv-vpn:~# cat /etc/openvpn/ccd/client1 iroute 172.200.200.0 255.255.255.0
Теперь мои пояснения самому себе:
172.200.200.0/24 -> это сеть за Mikrotik10.8.0.1 -> IP-адрес srv-vps после установления OpenVPN туннеля.
Client1 -> Именование файла для клиента (обязательно именуется, как сертификат клиента (client1.key,client1.crt). Здесь указывается маршрут, т.к. правильнее, чтобы сервис сам создавал его, а не брандмауэр.
client-config-dir -> определяем каталог, в котором будут находиться файлы, в которых будут объявлены сети клиентов. Имена файлов должны совпадать с CommonName сертификата клиента, за которым находятся сети, объявленные в файле.
На заметку: Т.к. у меня OpenVPN—сервер запускается от имени пользователя nobody, то должны быть вот такие права на файл client1: (Т.е. вида: 644)
root@srv-vpn:~# ls -l /etc/openvpn/ccd/client1 -rw-r--r-- 1 root root 34 Sep 19 23:01 /etc/openvpn/ccd/client1 root@srv-vpn:~# systemctl stop openvpn@server && systemctl start openvpn@server && systemctl status openvpn@server | head -n5 && netstat -tulpn | grep openvpn root@srv-vpn:~# netstat -tulpn | grep openvpn tcp 0 0 0.0.0.0:1194 0.0.0.0:* LISTEN 850/openvpn root@srv-vpn:~#
Проверяем, какой IP получил Mikrotik:
root@srv-vpn:~# tail -f /var/log/openvpn/openvpn-status.log Updated,Fri Sep 20 12:00:24 2019 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since client1,<WAN_IP_TELE2>:49708,1323628,330349,Fri Sep 20 09:27:46 2019 ROUTING TABLE Virtual Address,Common Name,Real Address,Last Ref 10.8.0.6,client1,<WAN_IP_TELE2>:49708,Fri Sep 20 10:44:13 2019 172.200.200.1/24,client1,<WAN_IP_TELE2>:49708,Fri Sep 20 09:27:46 2019 GLOBAL STATS Max bcast/mcast queue length,0 END ^C root@srv-vpn:~#
Проверяем, какие маршруты сейчас на srv-vpn:
root@srv-vpn:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default <GW_VPS> 0.0.0.0 UG 0 0 0 eth0 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0 10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 172.200.200.0 10.8.0.1 255.255.255.0 UG 0 0 0 tun0 <NETWORK_VPS> 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Отлично все есть.
Шаг №2: Изменяю Порт для SSH сервиса:
root@srv-vpn:~# nano /etc/ssh/sshd_config Port 33500 root@srv-vpn:~# systemctl restart ssh ekzorchik@navy:~$ ssh -l root WAN_VPS:IP -p 33500 root@srv-vpn:~# netstat -tulpn | grep 33500 tcp 0 0 0.0.0.0:33500 0.0.0.0:* LISTEN 8449/sshd tcp6 0 0 :::33500 :::* LISTEN 8449/sshd root@srv-vpn:~#
Шаг №3: Теперь настраиваем брандмауэр на srv-vpn, я буду использовать надстройку firewalld вместо чистого iptables, так как там для слишком сложные правила, а тут более просто и понятно. От 21.09.2019
Не использовать ufw и чистый iptables, форвардинг заработал только используя:
root@srv-vpn:~# firewall-cmd --add-masquerade --permanent success root@srv-vpn:~# firewall-cmd --add-forward-port=port=33500:proto=tcp:toport=22:toaddr=172.200.200.25 --permanent success root@srv-vpn:~# firewall-cmd --add-port=33500/tcp --permanent success root@srv-vpn:~# firewall-cmd --add-port=1194/tcp --permanent success root@srv-vpn:~# firewall-cmd --remove-port=22/tcp --permanent root@srv-vpn:~# firewall-cmd --reload success
где адрес 172.200.200.25 – это сеть за Mikrotik(ом), а точнее адрес моего гипервизора Debian 10 + Proxmox 6.
Шаг №4: Правило маскарандинга на Mikrotik в nat нужно т. к. если я через проброс порта подключился, нет правила нет выхода и интернет:
root@srv-debian:~# ping ya.ru ^C root@srv-debian:~# ping mail.ru ^C root@srv-debian:~# ping 8.8.8.8 ^C root@srv-debian:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=22.4 ms ^C --- 8.8.8.8 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev =
пинги пошли, когда правило включил. ОЧЕНЬ ВАЖНО.
Шаг №5: Проверяю сетевым сканером NMAP какая информация выдается при проверки порта 33500 ответственного на Port Forward трафика:
ekzorchik@navy:~$ nmap -p 33500 <WAN_VPS:IP> -Pn -vv Starting Nmap 7.01 ( https://nmap.org ) at 2019-09-20 10:38 MSK
Если есть такая строчка «33500/tcp open unknown syn-ack», то перенаправление отработаетЕсли есть такая строчка «33500/tcp filtered unknown no-response», то перенаправление не работает, форвардинг запрещен.Если есть такая строчка «ssh_connect_direct: needpriv 0», то не отрабатывает Forwarding правилами ufw. Ну по крайней мере у меня.
Шаг №6: Вот строчка как я подключаюсь к своему OpenVPN серверу по SSH:
ekzorchik@navy:~$ ssh -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" root@<WAN_VPS:IP> -p 33500 -vv
Итого, задача резервному удаленному подключению к своим системам даже если домашний провайдер предоставляет мне серый адрес, а не белый – реализуема. Так серый адрес выдается при использовании USB модема ZTE MF823D + SIM-карта Tele2. Опираясь на вышеуказанные действия, делаем проброс порта если нужно для RDP соединения. Но я бы сказал мало так оставлять, хоть да есть защита в виде firewalld, у себя я реализовал еще и связку firewalld + fail2ban, но об этом, наверное, в следующий раз. На этом у меня всё, с уважением автор блога Олло Александр aka ekzorchik.