L2TP без IPsec на Linux: 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, MTU и MRU од 1460 и DNS адреса до која клиентот може да стигне откако врската ќе се подигне. Акредитивите се повторно трета датотека, /etc/ppp/chap-secrets, каде второто поле мора да се совпадне со името на делот LNS, а четвртото може да закачи конкретна адреса од базенот.

Зошто тунелот се поврзува и потоа заглавува

Ethernet рамка од 1500 бајти не се вклопува во патека што веќе троши бајти на своите заглавија. Надворешното IPv4 заглавие чини 20, UDP 8, а L2TP заглавието околу 12, што остава 1460 за PPP и неговиот товар. Токму објавувањето на таа помала бројка во 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, потоа прифатете го излезниот тунелски сообраќај со FORWARD правило за -i ppp0 -o eth0 и повратниот сообраќај со огледалното правило плус -m state --state RELATED,ESTABLISHED. Направете ги тие правила трајни низ престартувањата, бидејќи сервер што се враќа без нив изгледа точно како расипана L2TP конфигурација.

Стигнувањето до сопствениот LAN на серверот е друга задача: додајте повратна рута за базенот на LAN рутерот или proxy ARP на серверот. Криењето на клиентите зад NAT кога нешто во LAN мора да им се обрати директно само закажува втора сесија за отстранување грешки подоцна.

Што не прави голиот стек и како да се провери

Ниту еден дел од овој стек не ги шифрира PPP рамките и ништо во него не го автентицира далечниот крај како серверот што навистина сте го избрале. MS-CHAPv2 навистина ја штити размената на акредитиви од слушач што само набљудува, но напаѓачот поставен на патеката сепак може да се вмеша во сесијата. Вградениот Windows клиент го нуди L2TP само во комбинација со IPsec, затоа сметајте на Linux, фирмверот на рутерите и клиентите од трети страни како ваши партнери. Третирајте ја голата конфигурација како дијагностичка скала, никогаш како место за запирање.

Проверете по фиксен редослед: стартувајте xl2tpd -D во преден план, гледајте го дневникот за PPP фазата, прочитајте ја доделената адреса од ip addr на двата краја, потоа фатете UDP 1701 за да потврдите дека податоците течат откако сесијата е подигната. Ако сите четири се совпаднат, а сообраќајот и понатаму не поминува, вината е во рутирањето, NAT или MTU, а не во самиот L2TP.