L2TP heb IPsec ar Linux: xl2tpd, pppd a NAT

PPP mewn amlen yw L2TP plaen, a dim arall. Mae'n cario eich fframiau; nid yw'n eu hamgryptio ac nid yw'n profi pwy sy'n eistedd ar y pen arall, a dyna pam mae bron pob defnydd yn llithro IPsec oddi tano. Mae yna resymau gonest dros redeg y fersiwn noeth o hyd: mainc labordy, cam mudo, neu gyswllt sydd eisoes y tu mewn i lwybr gwarchodedig arall.

Os ewch ymlaen, rhowch y rhybudd hwnnw yn y nodyn dylunio a'i adael yno. Yr hyn sy'n dilyn yw'r llwybr gweithredol rwy'n ei ddefnyddio ar westeion Debian a theulu RHEL: pa ffeil sy'n gyfrifol am beth, yr MTU sy'n atal y tagfa glasurol, a'r rheolau anfon sy'n gwneud y twnnel yn werth chweil.

Mae tair ffeil yn rhannu'r gwaith

Mae xl2tpd yn terfynu'r cyswllt rheoli ac yn trosglwyddo pob sesiwn i daemon PPP, felly mae'r ffurfweddiad wedi'i wasgaru dros ddau raglen nad ydynt byth yn darllen ffeiliau ei gilydd. Mae'r gwrandawr yn byw yn /etc/xl2tpd/xl2tpd.conf, y tu mewn i adran [lns default] sy'n enwi'r pwll cyfeiriadau gyda ip range, pen y gweinydd gyda local ip, a'r trosglwyddo i PPP gyda pppoptfile. Trowch require authentication = yes ymlaen, gadewch length bit a flow bit wedi'u galluogi, a dewiswch bwll nad yw unrhyw beth arall ar y gwesteiwr yn ei ddefnyddio.

Mae polisi PPP yn perthyn i ba bynnag ffeil y mae'r opsiwn hwnnw'n ei henwi, fel arfer /etc/ppp/options.xl2tpd: auth, gwrthodiadau ar gyfer pap, chap a mschap, require-mschap-v2, MTU ac MRU o 1460, a chyfeiriad DNS y gall y cleient ei gyrraedd ar ôl i'r cyswllt godi. Mae'r manylion mewngofnodi yn drydedd ffeil eto, /etc/ppp/chap-secrets, lle mae'n rhaid i'r ail faes gyd-fynd ag enw adran LNS a gall y pedwerydd faes binio cyfeiriad penodol o'r pwll.

Pam mae'r twnnel yn cysylltu ac yna'n hongian

Nid yw ffrâm Ethernet o 1500 beit yn ffitio y tu mewn i lwybr sy'n barod yn gwario beit ar ei benawdau ei hun. Mae'r bennawd IPv4 allanol yn costio 20, mae UDP yn costio 8, a phennawd L2TP tua 12, sy'n gadael 1460 i PPP a'i lwyth. Hysbysebu'r ffigur llai hwnnw yn PPP sy'n cadw pecynnau mawr rhag cael eu darnio neu eu gollwng yn dawel rhywle yn y canol.

Y symptom yw twnnel sy'n edrych yn iach nes bod traffig go iawn yn cyrraedd: mae pingiau a negeseuon rheoli yn mynd trwodd, mae copi ffeil yn hongian, nid oes dim yn y cofnod yn esbonio hynny. Gostyngwch MTU ac MRU gyda'i gilydd ar y ddau ben. Mae addasu'r cleient yn unig fel arfer yn troi tagfa galed yn un ysbeidiol, sy'n waeth i'w ddiagnosio.

Mae un porth yn cario dau sgwrs

Mae UDP 1701 o dan y ddwy hanner o'r protocol, ac mae'r un ffaith honno'n torri mwy o reolau wal dân nag unrhyw ran arall o'r gosodiad. Yn gyntaf daw cais dechrau-cyswllt-rheoli a'i ateb; nid yw'r cais sesiwn a'r cadarnhad sy'n dilyn yn sefydlu dim mwy na'r pâr dynodwr. Yna mae PPP yn cymryd drosodd, gyda rheolaeth cyswllt, yna dilysu, yna protocol rheoli IP i setlo cyfeiriadau. Mae gan bob cam ei eirfa ei hun yn y cofnod, ac nid oes yr un ohonynt yn cyhoeddi ei hun fel methiant L2TP.

Mae darllen cofnodiad yn union yn y drefn honno'n dweud wrthych pa gam a fethodd, ac ni fydd methiant dilysu PPP yn cael ei drwsio trwy olygu xl2tpd. Mae'r porth cyffredin yn esbonio methiant cyffredin arall: mae rheol sy'n caniatáu dim ond pecynnau cyntaf llif yn gadael i'r sesiwn sefydlu ac yna'n blocio'r trosglwyddiad. Caniatáu 1701 ar gyfer y sgwrs gyfan, y ddau gyfeiriad.

Gwneud y twnnel yn ddefnyddiol: anfon ymlaen a NAT

Nid yw sesiwn ar ei phen ei hun yn cyrraedd y gweinydd yn unig. Mae mynediad rhyngrwyd y cleient angen anfon ymlaen, rheol NAT ar gyfer y pwll ar y cyswllt i fyny, a DNS y gall y cleient ei ymholi mewn gwirionedd ar ôl i'r cyswllt godi. Mae'n rhaid i'r pwll hefyd aros yn glir o ystod y LAN, neu bydd atebion a gyfeiriwyd at gleientiaid yn cael eu danfon yn lleol yn lle eu gwthio'n ôl i'r twnnel.

Ar y gweinydd, galluogwch anfon ymlaen gyda sysctl -w net.ipv4.ip_forward=1, cyfieithwch y pwll gyda iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, yna derbyniwch draffig twnnel allanol gyda rheol FORWARD ar gyfer -i ppp0 -o eth0 a thraffig dychwelyd gyda'r rheol drych ynghyd â -m state --state RELATED,ESTABLISHED. Cadwch y rheolau hynny ar draws ailgychwyn, oherwydd mae gweinydd sy'n dychwelyd hebddyn nhw yn edrych yn union fel ffurfweddiad L2TP wedi torri.

Mae cyrraedd LAN y gweinydd ei hun yn dasg wahanol: ychwanegwch lwybr dychwelyd ar gyfer y pwll ar y llwybrydd LAN, neu proxy ARP ar y gweinydd. Mae cuddio cleientiaid y tu ôl i NAT pan fydd rhywbeth yn y LAN yn gorfod cyfeirio atynt yn uniongyrchol yn amserlennu ail sesiwn dadfygio yn ddiweddarach.

Beth nad yw'r stac noeth yn ei wneud, a sut i wirio

Nid oes unrhyw ran o'r stac hwn yn amgryptio'r fframiau PPP, ac nid oes dim ynddo'n dilysu'r pen pell fel y gweinydd a ddewiswyd gennych mewn gwirionedd. Mae MS-CHAPv2 yn gwarchod y cyfnewid manylion mewngofnodi rhag gwrandawr sy'n gwylio'n unig, ond gall ymosodwr sydd wedi'i leoli yn y llwybr ymyrryd â'r sesiwn o hyd. Mae cleient brodorol Windows yn cynnig L2TP dim ond ar y cyd ag IPsec, felly cyllidebwch ar gyfer Linux, cadarnwedd llwybryddion a chleientiaid trydydd parti fel eich cymheiriaid. Triniwch y ffurfweddiad noeth fel carreg gamu ddiagnostig, byth fel y man i stopio.

Gwiriwch mewn trefn sefydlog: rhedegwch xl2tpd -D yn y blaendir, gwyliwch y cofnod ar gyfer cam PPP, darllenwch y cyfeiriad a neilltuwyd o ip addr ar y ddau ben, yna cofnodwch UDP 1701 i gadarnhau bod data'n llifo ar ôl i'r sesiwn godi. Os yw'r pedwar yn cyd-fynd ac mae traffig yn dal i fethu, y nam yw llwybro, NAT neu MTU yn hytrach na L2TP ei hun.