Linux-та IPsec-сіз L2TP: xl2tpd, pppd және NAT

Жалаң L2TP — конверт ішіндегі PPP, басқа ештеңе емес. Ол кадрларыңызды тасымалдайды; оларды шифрламайды және арғы жақта кім отырғанын дәлелдемейді, сондықтан дерлік барлық орнату оның астына IPsec салады. Жалаң нұсқаны іске қосудың адал себептері әлі де бар: зертханалық стенд, көшу қадамы немесе басқа қорғалған жолдың ішінде тұрған байланыс.

Егер бәрібір жалғастырсаңыз, бұл ескертуді дизайн жазбасына жазып, сол жерде қалдырыңыз. Әрі қарай — Debian және RHEL тұқымдасының хосттарында қолданатын операциялық жол: қай файл не үшін жауапты, классикалық қатып қалуды болдырмайтын MTU және туннельді құнды ететін қайта бағыттау ережелері.

Үш файл жұмысты бөледі

xl2tpd басқару қосылымын аяқтап, әр сессияны PPP демонына береді, сондықтан конфигурация бір-бірінің файлдарын ешқашан оқымайтын екі бағдарламаға бөлінген. Тыңдаушы /etc/xl2tpd/xl2tpd.conf ішінде, [lns default] бөлімінің ішінде тұрады, ол мекенжай пулын ip range-пен, сервер жағын local ip-пен және PPP-ге берілуін pppoptfile-пен атайды. require authentication = yes қосыңыз, length bit және flow bit қосулы қалсын, ал хостта басқа ештеңе пайдаланбайтын пулды таңдаңыз.

PPP саясаты осы параметр атайтын файлға тиесілі, әдетте /etc/ppp/options.xl2tpd: auth, pap, chap және mschap үшін бас тартулар, require-mschap-v2, 1460 MTU мен MRU, және байланыс көтерілгеннен кейін клиент жете алатын DNS мекенжайы. Тіркелу деректері тағы үшінші файл, /etc/ppp/chap-secrets, онда екінші өріс LNS бөлімінің атауына сәйкес болуы керек, ал төртінші өріс пулдан нақты мекенжайды бекіте алады.

Туннель неге қосылып, сосын қатып қалады

1500 байттық Ethernet кадры өз тақырыптарына байт жұмсап қойған жолға сыймайды. Сыртқы IPv4 тақырыбы 20 алады, UDP 8, ал L2TP тақырыбы шамамен 12, бұл PPP мен оның пайдалы жүктемесіне 1460 қалдырады. Дәл осы кіші санды PPP-де жариялау үлкен пакеттердің бөлшектенуіне немесе ортада бір жерде үнсіз жоғалуына жол бермейді.

Симптом — нақты трафик келгенге дейін сау көрінетін туннель: пингтер мен басқару хабарлары өтеді, файл көшіру қатып қалады, журналда оны түсіндіретін ештеңе жоқ. Екі шетінде MTU мен MRU-ды бірге төмендетіңіз. Тек клиентті реттеу әдетте қатты қатып қалуды үзік-үзік қатып қалуға айналдырады, оны диагностикалау қиынырақ.

Бір порт екі әңгімені тасымалдайды

UDP 1701 хаттаманың екі жартысының да астында жатыр, және осы бір факт қондырғының кез келген басқа бөлігінен гөрі көбірек брандмауэр ережелерін бұзады. Алдымен басқару қосылымын бастау сұранысы мен оның жауабы келеді; одан кейінгі сессия сұранысы мен растау сәйкестендіргіш жұбынан артық ештеңе орнатпайды. Содан кейін PPP тізгінді алады: байланыс басқаруы, сосын аутентификация, сосын мекенжайларды келісу үшін IP басқару хаттамасы. Әр кезеңнің журналда өз сөздігі бар және олардың ешқайсысы өзін L2TP ақауы ретінде жарияламайды.

Жазбаны дәл осы ретпен оқу қай кезеңнің сәтсіз болғанын айтады, ал PPP аутентификациясының сәтсіздігі xl2tpd-ні өңдеумен түзелмейді. Ортақ порт тағы бір жиі кездесетін ақауды түсіндіреді: ағынның тек алғашқы пакеттеріне рұқсат беретін ереже сессияның орнығуына жол береді, содан кейін тасымалдауды бөгейді. 1701-ге бүкіл әңгіме үшін, екі бағытта да рұқсат етіңіз.

Туннельді пайдалы ету: қайта бағыттау және NAT

Сессия өздігінен тек серверге жетеді. Клиенттің интернетке шығуы үшін қайта бағыттау, жоғары арнада пул үшін NAT ережесі және байланыс көтерілгеннен кейін клиент шынымен сұрай алатын DNS қажет. Пул LAN ауқымынан тыс тұруы керек, әйтпесе клиенттерге арналған жауаптар туннельге кері итерілудің орнына жергілікті жерде жеткізіледі.

Серверде қайта бағыттауды sysctl -w net.ipv4.ip_forward=1-мен қосыңыз, пулды iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE-мен аударыңыз, содан кейін -i ppp0 -o eth0 үшін FORWARD ережесімен шығыс туннель трафигін және айна ережесіне қоса -m state --state RELATED,ESTABLISHED-пен қайтарылатын трафикті қабылдаңыз. Бұл ережелерді қайта жүктеулер арасында сақтап қалыңыз, өйткені оларсыз қайта оралған сервер дәл бұзылған L2TP конфигурациясына ұқсайды.

Сервердің өз LAN-ына жету — басқа міндет: LAN маршрутизаторында пул үшін қайтару маршрутын қосыңыз немесе серверде proxy ARP іске қосыңыз. LAN ішіндегі бірдеңе клиенттерге тікелей жүгінуі керек болғанда оларды NAT артына жасыру тек кейінге екінші жөндеу сессиясын жоспарлайды.

Жалаң стек не істемейді және оны қалай тексеру керек

Бұл стектің ешбір бөлігі PPP кадрларын шифрламайды және онда ештеңе алыс жақты сіз шынымен таңдаған сервер ретінде аутентификацияламайды. MS-CHAPv2 тіркелу деректерінің алмасуын тек бақылаушы тыңдаушыдан қорғайды, бірақ жолда орналасқан шабуылдаушы сессияға әлі де араласа алады. Windows-тың жергілікті клиенті L2TP-ні тек IPsec-пен бірге ұсынады, сондықтан Linux, маршрутизатор прошивкасы және үшінші тарап клиенттерін серіктес ретінде есептеңіз. Жалаң конфигурацияны диагностикалық саты ретінде қарастырыңыз, ешқашан тоқтайтын орын ретінде емес.

Бекітілген тәртіппен тексеріңіз: xl2tpd -D командасын алдыңғы планда іске қосыңыз, PPP кезеңі үшін журналды қадағалаңыз, екі шетінде ip addr ішінен берілген мекенжайды оқыңыз, содан кейін сессия көтерілгеннен кейін деректер ағып жатқанын растау үшін UDP 1701-ді ұстаңыз. Егер төртеуі де сәйкес келсе де трафик әлі өтпейтін болса, кінә маршрутизацияда, NAT-та немесе MTU-да, L2TP-нің өзінде емес.