L2TP bila IPsec kwenye Linux: xl2tpd, pppd na NAT

L2TP tupu ni PPP ndani ya bahasha, na si kitu kingine. Hubeba fremu zako; haizisimbi na haithibitishi nani amekaa upande wa pili, ndiyo sababu karibu kila usambazaji huweka IPsec chini yake. Sababu za uaminifu za kutumia toleo tupu bado zipo: benchi ya maabara, hatua ya uhamishaji, au kiungo ambacho tayari kiko ndani ya njia nyingine iliyolindwa.

Ukiamua kuendelea, andika onyo hilo kwenye kidokezo cha muundo na uliache pale. Kinachofuata ni njia ya uendeshaji ninayotumia kwenye wenyeji wa familia ya Debian na RHEL: faili gani inahusika na nini, MTU inayozuia kukwama kwa kawaida, na kanuni za upelekaji zinazofanya handaki kuwa na thamani.

Faili tatu zinagawana kazi

xl2tpd hukomesha muunganisho wa udhibiti na hukabidhi kila kikao kwa daemon ya PPP, kwa hivyo usanidi umegawanyika kati ya programu mbili ambazo hazisomi faili za nyingine kamwe. Msikilizaji anaishi katika /etc/xl2tpd/xl2tpd.conf, ndani ya sehemu ya [lns default] inayotaja bwawa la anwani kwa ip range, upande wa seva kwa local ip, na ukabidhishaji kwa PPP kwa pppoptfile. Washa require authentication = yes, acha length bit na flow bit zikiwa imewashwa, na chagua bwawa ambalo hakuna kitu kingine kwenye mwenyeji linalotumia.

Sera ya PPP ni ya faili ambalo chaguo hilo linataja, kwa kawaida /etc/ppp/options.xl2tpd: auth, kukataliwa kwa pap, chap na mschap, require-mschap-v2, MTU na MRU ya 1460, na anwani ya DNS ambayo mteja anaweza kufikia baada ya kiungo kupanda. Vitambulisho ni faili ya tatu tena, /etc/ppp/chap-secrets, ambapo uga wa pili lazima ulingane na jina la sehemu ya LNS na uga wa nne unaweza kubandika anwani mahususi kutoka bwawani.

Kwa nini handaki huungana kisha kukwama

Fremu ya Ethernet ya baiti 1500 haitoshi ndani ya njia ambayo tayari inatumia baiti kwenye vichwa vyake yenyewe. Kichwa cha nje cha IPv4 kinatumia 20, UDP 8, na kichwa cha L2TP karibu 12, kinachobakiza 1460 kwa PPP na mzigo wake. Kutangaza nambari hiyo ndogo katika PPP ndiko kunakozuia pakiti kubwa kugawanywa au kutupwa kimya mahali fulani katikati.

Dalili ni handaki inayoonekana yenye afya hadi trafiki halisi ifike: ping na jumbe za udhibiti hupita, kunakili faili kunakwama, hakuna kitu kwenye kumbukumbu kinachoeleza. Punguza MTU na MRU pamoja kwenye miisho yote miwili. Kurekebisha mteja pekee kwa kawaida hubadilisha kukwama kwa nguvu kuwa kwa vipindi, jambo ambalo ni gumu zaidi kutambua.

Bandari moja hubeba mazungumzo mawili

UDP 1701 iko chini ya nusu zote mbili za itifaki, na ukweli huo mmoja huvunja kanuni za firewall zaidi kuliko sehemu nyingine yoyote ya usanidi. Kwanza huja ombi la kuanza muunganisho wa udhibiti na jibu lake; ombi la kikao na uthibitisho unaofuata haviweki chochote zaidi ya jozi ya vitambulisho. Kisha PPP inachukua nafasi: udhibiti wa kiungo, kisha uthibitishaji, kisha itifaki ya udhibiti wa IP ili kukubaliana anwani. Kila hatua ina msamiati wake kwenye kumbukumbu, na hakuna hata moja inayojitangaza kama kushindwa kwa L2TP.

Kusoma rekodi kwa mpangilio huo hasa hukuambia hatua ipi ilishindwa, na kushindwa kwa uthibitishaji wa PPP hakutarekebishwa kwa kuhariri xl2tpd. Bandari inayoshirikiwa inaeleza kushindwa kingine cha kawaida: kanuni inayoruhusu pakiti za kwanza tu za mtiririko huacha kikao kianzishwe kisha huzuia uhamishaji. Ruhusu 1701 kwa mazungumzo yote, pande zote mbili.

Kuifanya handaki kuwa muhimu: upelekaji na NAT

Kikao chenyewe hufikia seva pekee. Ufikiaji wa intaneti wa wateja unahitaji upelekaji, kanuni ya NAT kwa bwawa kwenye kiungo cha juu, na DNS ambayo mteja anaweza kuiuliza kweli baada ya kiungo kupanda. Bwawa lazima pia libaki nje ya wigo wa LAN, vinginevyo majibu yaliyoelekezwa kwa wateja huwasilishwa ndani badala ya kusukumwa nyuma kwenye handaki.

Kwenye seva, washa upelekaji kwa sysctl -w net.ipv4.ip_forward=1, tafsiri bwawa kwa iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, kisha kubali trafiki ya handaki inayotoka kwa kanuni ya FORWARD kwa -i ppp0 -o eth0 na trafiki inayorudi kwa kanuni ya kioo pamoja na -m state --state RELATED,ESTABLISHED. Fanya kanuni hizo kudumu kati ya kuwasha upya, kwa sababu seva inayorudi bila hizo inaonekana sawa kabisa na usanidi wa L2TP uliovunjika.

Kufikia LAN ya seva yenyewe ni kazi nyingine: ongeza njia ya kurudi kwa bwawa kwenye kipanga njia cha LAN, au proxy ARP kwenye seva. Kuwaficha wateja nyuma ya NAT wakati kitu ndani ya LAN kinapaswa kuwaelekea moja kwa moja ni kupanga kikao cha pili cha utatuzi wa hitilafu baadaye.

Rundo tupu halifanyi nini, na jinsi ya kuthibitisha

Hakuna sehemu ya rundo hili inayosimba fremu za PPP, na hakuna kitu ndani yake kinachothibitisha upande wa mbali kama seva uliyoichagua kweli. MS-CHAPv2 hulinda ubadilishanaji wa vitambulisho dhidi ya msikilizaji anayetazama tu, lakini mshambuliaji aliye kwenye njia bado anaweza kuingilia kikao. Mteja asilia wa Windows hutoa L2TP pamoja na IPsec pekee, kwa hivyo hesabu Linux, firmware za vipanga njia na wateja wa wahusika wengine kama washirika wako. Chukulia usanidi tupu kama hatua ya utambuzi, kamwe si mahali pa kuacha.

Thibitisha kwa mpangilio maalum: endesha xl2tpd -D mbele, angalia jarida kwa hatua ya PPP, soma anwani iliyotolewa kutoka ip addr kwenye miisho yote miwili, kisha nasa UDP 1701 ili kuthibitisha kwamba data inatiririka baada ya kikao kupanda. Iwapo zote nne zinalingana na trafiki bado inashindwa, hitilafu iko kwenye uelekezaji, NAT au MTU, si kwenye L2TP yenyewe.