Сервер PPTP за хатнім роўтарам: спачатку выправіць 1723 і GRE

PPTP за хатнім роўтарам адмаўляе двума непавязанымі спосабамі, і блытаніна паміж імі марнуе вечар. Адна адмова — прабел у перасылцы: роўтар прапускае TCP 1723 і скідае IP-пратакол 47, таму кліент вісне на памылцы 619. Другая — праблема памеру: тунель уздымаецца, праходзіць аўтэнтыфікацыю, а затым замірае, калі павінен прайсці пакет поўнага памеру. Вызначыць, якая з іх у вас, — гэта першы сапраўдны крок; астатняе параўноўвае тое, што можа выразіць ваш роўтар, а не тое, які брэнд лепшы.

Два транспарты, і толькі ў аднаго ёсць порт

PPTP дзеліцца на два транспарты: кантрольнае злучэнне на TCP 1723 і кадры PPP, загорнутыя ў пашыраны GRE, гэта значыць IP-пратакол 47. У GRE няма нумара порта, таму правіла, запісанае як перасылка порта 1723, не можа яго пакрыць, як бы вэб-інтэрфейс ні называў гэтае поле. Спажывецкі роўтар звычайна прапануе птушку з назвай праход PPTP замест правіла пратакола, і гэтая птушка робіць дзве справы: дазваляе пратаколу 47 прайсці праз сістэму аховы і вучыць NAT адсочваць паток GRE. На Linux-роўтары гэта асобныя модулі і асобныя правілы, таму напалову настроены праход усё яшчэ дае працоўны канал кіравання. Высветліце, якая палова прысутнічае, перш чым нешта змяняць.

Уласная сістэма аховы сервера таксама павінна дазваляць пратакол 47 з адраса роўтара. Гаспадарчая сістэма аховы, якая прымае толькі 1723/tcp, узнаўляе памылку 619 знутры LAN, і таму зламаная перасылка і зламанае правіла гаспадара выглядаюць аднолькава.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

Калі модуляў няма, загрузіце іх праз sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre і зрабіце загрузку пастаяннай, бо перазапуск, які забывае памочніка, зноў ператварае працоўны тунель у памылку 619. Правіла перасылкі павінна прымаць пратакол 47 толькі ў бок адраса сервера, а не ўсяй LAN. Вызначэнне RFC 2637 аддзяляе шляхі кіравання і даных, таму ніводны экран перасылкі порта не апісвае PPTP цалкам.

Птушка праходу ці яўнае правіла пратакола

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

Правіла NAT прызначэння для 1723 таксама мае праблему ўласніка. Калі састарэлае правіла ўсё яшчэ шле 1723 на хост, які спыніў сервер, пакеты трапляюць на закрыты порт, і ўласная служба PPTP роўтара перастае адказваць, што чытаецца як збой сістэмы аховы, а насамрэч гэта састарэлая мэта. Прачытайце правіла і яго прызначэнне, перш чым дадаваць другое. На роўтарах, якія самі завяршаюць PPTP, правіла WAN канкуруе з убудаванай службай, таму выберыце аднаго ўласніка для 1723 і пратакола 47.

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

Памерайце тунель, перш чым вінаваціць роўтар

PPTP паменшвае карысную наванрузку, і гэтае паменшанне — арыфметыка, а не загадка. Кожны пакет тунеля нясе знешні загаловак IP, пашыраны загаловак GRE, загаловак PPP і, з шыфраваннем, загаловак MPPE. Калі шлях не можа пранесці атрыманы кадр, дробныя пакеты праходзяць, уваход завяршаецца, і сеанс спыняецца ўпершыню, калі перадача файла або рукапаціск TLS шле пакет поўнага памеру.

Палічыце лік замест здагадкі. Пашыраны GRE каштуе 8 байтаў, PPP — 4, MPPE — 4, а знешні загаловак IP — 20, таму тунель з'ядае 36 байтаў да любой наванрузкі. На WAN з PPPoE, які мае мяжу 1492, найбольшы PPP MTU, што змяшчаецца, — гэта 1492 мінус 36, гэта значыць 1456. Задайце mtu і mru гэтае значэнне ў параметрах PPP і праверце зноў пінгам без фрагментацыі.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

Пінг мерае шлях, а не тунель: 1464 байты наванрузкі плюс 28 байтаў загалоўкаў IP і ICMP роўна запаўняюць кадр у 1492 байты. Калі гэты пінг не праходзіць, зніжайце лік, пакуль ён не пройдзе, і адніміце 36 ад выніку. MTU тунеля, усталяваны вышэй за мяжу шляху, выклікае заміранне без адзінага радка журнала, дзе згадваецца памер.

PPTP, L2TP/IPsec ці OpenVPN на адным роўтары

Адзін і той жа роўтар можа несці любы з трох звычайных тунеляў, і розніца ў тым, што ён павінен выразіць. PPTP патрабуе два правілы ў двух розных пластах. L2TP паверх IPsec патрабуе UDP 500 і 4500 для абмену ключамі і, калі NAT-T не нясе яго, пратакол 50 для наванрузкі. OpenVPN патрабуе адзін порт UDP і зусім не патрабуе памочніка.

Калона L2TP не аўтаматычна сяброўская да GRE. ESP — гэта IP-пратакол 50, і ў яго таксама няма порта, таму роўтар, які мае цяжкасці з пратаколам 47, можа мець тыя ж цяжкасці з пратаколам 50. NAT-T існуе, каб загарнуць ESP у UDP 4500, і калі абодва канцы яго падтрымліваюць, правіла пратакола 50 робіцца непатрэбным. Гэта ўласцівасць канцоў, а не птушкі PPTP роўтара. Пацвердзіце, якую інкапсуляцыю кліент насамрэч узгадніў, перш чым пісаць правілы для абодвух.

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

Што рамантаваць і што замяняць

Выпраўленне перасылкі і MTU дае тунель, які працуе, а не той, які варта пакідаць. Аўтэнтыфікацыя MSCHAPv2 у PPTP ужо гады паддаецца атацы, а працоўны тунель перадае ўліковыя даныя, якія можна аднавіць афлайн. Калі аддаленая прылада можа запусціць L2TP/IPsec або OpenVPN, лічыце рамант часовым захадам з датай.

Рашэнне зводзіцца да таго, што падтрымлівае далёкі канец і колькі ўвесь лад павінен пратрымацца. Старая прылада, якая разумее толькі PPTP, атрымлівае рамант; усё, што можа ўсталяваць кліент, мігруе.

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