Жөнөкөй 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нин өзүндө эмес.

Тектеш макалалар