L2TP bez IPsec operētājsistēmā Linux: xl2tpd, pppd un NAT

Kailais L2TP ir PPP aploksnē, un nekas vairāk. Tas pārnēsā jūsu kadrus; tas tos nešifrē un nepierāda, kas sēž otrā galā, tāpēc gandrīz katrs ieviešanas projekts zem tā iebāž IPsec. Godīgi iemesli darbināt kailo versiju joprojām pastāv: laboratorijas sols, migrācijas solis vai saite, kas jau atrodas citā aizsargātā ceļā.

Ja tomēr turpināt, ierakstiet šo brīdinājumu dizaina piezīmē un atstājiet to tur. Turpmākais ir operatīvais ceļš, ko izmantoju Debian un RHEL saimes hostos: kura datne par ko atbild, MTU, kas novērš klasisko iestrēgšanu, un pāradresācijas noteikumi, kas tuneļa iekārtošanu padara to vērtu.

Trīs datnes dala darbu

xl2tpd pārtrauc vadības savienojumu un nodod katru sesiju PPP dēmonam, tāpēc konfigurācija ir sadalīta starp divām programmām, kas nekad nelasa viena otras datnes. Klausītājs mīt /etc/xl2tpd/xl2tpd.conf, [lns default] sadaļā, kas adrešu kopu nosauc ar ip range, servera galu ar local ip un nodošanu PPP ar pppoptfile. Ieslēdziet require authentication = yes, atstājiet length bit un flow bit ieslēgtus un izvēlieties kopu, ko resursā vēl neizmanto nekas cits.

PPP politika pieder tai datnei, ko nosauc šī opcija, parasti /etc/ppp/options.xl2tpd: auth, atteikumi pap, chap un mschap, require-mschap-v2, MTU un MRU 1460, un DNS adrese, ko klients var sasniegt pēc saites pacelšanas. Akreditācijas dati atkal ir trešā datne, /etc/ppp/chap-secrets, kur otrajam laukam jāsakrīt ar LNS sadaļas nosaukumu, bet ceturtais lauks var piespraust konkrētu adresi no kopas.

Kāpēc tunelis pieslēdzas un tad iestrēgst

1500 baitu Ethernet kadrs neietilpst ceļā, kas jau tērē baitus saviem galvenēm. Ārējā IPv4 galvene aizņem 20, UDP - 8, bet L2TP galvene - apmēram 12, kas atstāj 1460 PPP un tā kravai. Tieši šī mazākā skaitļa paziņošana PPP attur lielos paketes no sadalīšanas vai klusas nomešanas kaut kur pa vidu.

Simptoms ir tunelis, kas izskatās vesels, līdz pienāk īsta plūsma: pingi un vadības ziņojumi iziet, datnes kopēšana iestrēgst, nekas žurnālā to neizskaidro. Samaziniet MTU un MRU kopā abos galos. Pielāgojot tikai klientu, ciets iestrēgums parasti pārvēršas neregulārā, ko ir grūtāk diagnosticēt.

Viens ports nes divas sarunas

UDP 1701 atrodas zem abām protokola pusēm, un šis vienīgais fakts salauž vairāk ugunsmūra noteikumu nekā jebkura cita iestatījuma daļa. Vispirms nāk vadības savienojuma sākuma pieprasījums un tā atbilde; pēc tam sekojošais sesijas pieprasījums un apstiprinājums neizveido neko vairāk par identifikatoru pāri. Tad pārņem PPP: saites vadība, pēc tam autentifikācija, pēc tam IP vadības protokols adrešu saskaņošanai. Katram posmam žurnālā ir sava valoda, un neviens no tiem neizziņo sevi kā L2TP kļūdu.

Ieraksta lasīšana tieši šajā secībā pasaka, kurš posms neizdevās, un PPP autentifikācijas kļūmi neizlabos xl2tpd rediģēšana. Kopīgais ports izskaidro vēl vienu biežu kļūmi: noteikums, kas atļauj tikai plūsmas pirmos paketes, ļauj sesijai izveidoties un pēc tam bloķē pārsūtīšanu. Atļaujiet 1701 visai sarunai, abos virzienos.

Padarīt tuneli noderīgu: pāradresācija un NAT

Sesija pati par sevi sasniedz tikai serveri. Klientu interneta piekļuvei vajadzīga pāradresācija, NAT noteikums kopai augšuplinkā un DNS, ko klients pēc saites pacelšanas patiešām var pieprasīt. Kopai jāpaliek arī ārpus LAN diapazona, citādi klientiem adresētās atbildes tiek piegādātas lokāli, nevis iespiestas atpakaļ tunelī.

Serverī ieslēdziet pāradresāciju ar sysctl -w net.ipv4.ip_forward=1, pārtulkojiet kopu ar iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, pēc tam pieņemiet izejošo tuneļa plūsmu ar FORWARD noteikumu -i ppp0 -o eth0 un atgriešanās plūsmu ar spoguļa noteikumu plus -m state --state RELATED,ESTABLISHED. Padariet šos noteikumus noturīgus starp pārstartēšanām, jo serveris, kas atgriežas bez tiem, izskatās tieši kā salauzta L2TP konfigurācija.

Nokļūšana paša servera LAN ir cits uzdevums: pievienojiet atgriešanās maršrutu kopai LAN maršrutētājā vai proxy ARP serverī. Klientu slēpšana aiz NAT, kad kaut kam LAN iekšienē tie ir jāuzrunā tieši, tikai ieplāno otru atkļūdošanas sesiju vēlākam laikam.

Ko kailais steks nedara un kā to pārbaudīt

Neviena šī steka daļa nešifrē PPP kadrus, un nekas tajā neautentificē tālo galu kā serveri, kuru jūs patiešām izvēlējāties. MS-CHAPv2 gan aizsargā akreditācijas datu apmaiņu no klausītāja, kas tikai vēro, taču uzbrucējs ceļā joprojām var iejaukties sesijā. Windows iebūvētais klients piedāvā L2TP tikai kopā ar IPsec, tāpēc rēķinieties ar Linux, maršrutētāju programmaparatūru un trešo pušu klientiem kā saviem partneriem. Uztveriet kailo konfigurāciju kā diagnostikas pakāpienu, nekad kā vietu, kur apstāties.

Pārbaudiet fiksētā secībā: palaidiet xl2tpd -D priekšplānā, vērojiet žurnālu PPP posmam, nolasiet piešķirto adresi no ip addr abos galos, pēc tam ierakstiet UDP 1701, lai apstiprinātu, ka dati plūst pēc sesijas pacelšanas. Ja visi četri sakrīt un plūsma joprojām neiet, vaina ir maršrutēšanā, NAT vai MTU, nevis pašā L2TP.