Публічны прэфікс праз OpenVPN: выпраўленне зваротнага шляху

Паназірайце, як узнімаецца тунель і кліент пінгуе процілеглы бок, а затым публічны адрас, які належыць за VPN, адказвае аднекуль іншага або не адказвае зусім. Гэты сімптом звычайна не мае нічога агульнага з шыфрам або сертыфікатамі. Прэфікс, маршрутызаваны правайдрам, дастаўляецца як IP-маршрут, і перанесці яго праз OpenVPN азначае ўзнавіць гэты маршрут на двух узроўнях і захаваць адрас крыніцы на зваротным шляху. Маставаць WAN не патрабуецца, і даданне адраса да інтэрфейса не стварае вышэйшы маршрут.

Прэфікс спачатку трэба маршрутызаваць да вас

Спытайце правайдра, як дастаўляецца блок. Прэфікс, маршрутызаваны на асноўны адрас вашага сервера, — гэта іншая справа, чым адрасы, якія правайдар чакае бачыць непасрэдна на сегменце WAN. Толькі першая мадэль працуе з дызайнам тут.

Калі правайдар маршрутызуе 198.51.100.64/28 на ваш уваходны сервер, пакеты для гэтага дыяпазону прыходзяць на сервер і спыняюцца там, пакуль вы іх не перасылаеце. Калі ж правайдар замест гэтага мастуе дыяпазон на ваш up-link, сервер павінен адказваць на ARP для яго, а гэта іншая праблема.

Праверце мадэль дастаўкі, перш чым кранаць OpenVPN: звонку запінгуйце адрас у блоку і паназірайце, які інтэрфейс яго атрымлівае. Калі нічога не прыходзіць, ніякая канфігурацыя тунеля не дапаможа. Калі адрас адказвае непасрэдна на WAN, правайдар мастуе, а не маршрутызуе, і дызайн ніжэй не падыходзіць.

Два ўзроўні маршрутызацыі: маршрут ядра і iroute

OpenVPN патрэбны прэфікс у двух месцах. Ядро павінна ведаць, што прэфікс належыць прыладзе тунеля, каб перасылаемыя пакеты траплялі ў OpenVPN, а не ў маршрут па змаўчанні. OpenVPN таксама павінен ведаць, які аўтэнтыфікаваны кліент валодае прэфіксам, і гэта запіс iroute ў каталогу, спецыфічным для кліента.

Маршрут на баку сервера выглядае так, прычым прэфікс і маска павінны адпавядаць выдзяленню:

ip route add 198.51.100.64/28 dev tun0

Канфігурацыя, спецыфічная для кліента, прызначае ўладанне. Змесціце яе ў файл CCD, названы па агульным імені сертыфіката кліента, і пераканайцеся, што менавіта гэты каталог сервер сапраўды чытае:

iroute 198.51.100.64 255.255.255.240

Дакументацыя OpenVPN пра маршрутызаваныя сеткі апісвае абодва ўзроўні і тое, чаму яны асобныя. Маршрут ядра без iroute адпраўляе пакеты ў тунель без уладальніка, і OpenVPN іх скідае. iroute без маршруту ядра пакідае пакеты на шляху сервера па змаўчанні. Абедзве памылкі выглядаюць з боку кліента як зламаны тунель.

Дзе жыве адрас службы

Дэлегаваны прэфікс — не тое самае, што ўласныя адрасы тунеля. Нумаруйце злучэнне з прыватнай прасторы, калі хочаце, і размясціце публічны адрас службы там, дзе служба сапраўды працуе.

На кліенце Linux, які лакальна завершвае службу, дастаткова адраса асобнага хоста:

ip address add 198.51.100.70/32 dev lo

Калі прэфікс маршрутызуецца далей на хост VM або іншую LAN, замест гэтага наладзьце гэты ніжні шлях і яго зваротны маршрут. Прызначаць кожны адрас у блоку VPN-кліенту не патрабуецца, і гэта стварае канфлікты пазней.

Захавайце публічную крыніцу на зваротным шляху

Адказ з дэлегаванага прэфікса павінен выйсці праз тунель і дасягнуць маршруту правайдра. Калі аддалены хост адпраўляе яго праз свайго ISP, адрас крыніцы выглядае падробленым, і правайдар або прызначэнне яго скідаюць. Выпраўленне — правіла на аснове крыніцы або асобная табліца маршрутызацыі, а не шырэйшы NAT. Без яго служба працуе ад суседа па тунелі і зрываецца з усіх іншых месцаў.

На ўваходным серверы шырокае правіла masquerade — звычайны віноўнік. Яно перапісвае публічную крыніцу на асноўны адрас сервера, і кліент ніколі не бачыць сапраўдны:

iptables -t nat -S POSTROUTING

Абмяжуйце NAT прыватнымі VPN-кліентамі, якім ён патрэбны, і пакіньце дэлегаваны прэфікс без пераўтварэння. Затым пераканайцеся, што сервер наогул перасылае прэфікс, бо ланцуг перасылкі з забаронай па змаўчанні скідае яго моўчкі.

Праверце абодва кірункі, перш чым давяраць

Праверка — гэта чатыры назіранні, а не адно. Пераканайцеся, што маршрут правайдра прыходзіць, ядро адпраўляе прэфікс у тунель, OpenVPN прыпісвае яго правільнаму кліенту, а адказ вяртаецца з цэлым публічным адрасам крыніцы. Кожнае назіранне мае сваю каманду, таму збой паказвае на ўзровень, а не на ўвесь дызайн. Выконвайце іх у гэтым парадку пасля кожнага змянення канфігурацыі.

Спытайце ядро, які шлях выбірае дэлегаваны адрас, і паназірайце за тунелем, пакуль выконваецца запыт:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Фільтрацыя зваротнага шляху можа адмяніць правільны маршрут. Праверце эфектыўны параметр на тунелі і на up-link і памятайце, што строгі рэжым адхіляе трафік, крыніца якога не адпавядае інтэрфейсу, на які ён прыйшоў:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Нарэшце, праверце выпадак збою. Спыніце тунель і пераканайцеся, што публічны прэфікс не ўцякае праз звычайны up-link. Аднаўленне VPN павінна вярнуць службу, не пашыраючы порты, якія хост адкрывае.