L2TP/IPsec sa pamamagitan ng NAT: ano talaga ang nasisira at bakit

Ang sinasabi na sinisira ng NAT ang L2TP/IPsec ay kalahating totoo at kaya walang silbi. Normal ang pagasa ng address, umiiral ang NAT traversal para lamang mabuhay mula rito, at milyon-milyong kliyente ang kumokonekta araw-araw mula sa likod ng router. Ang nasisira ay isang partikular na yugto ng isang partikular na palitan: hindi kailanman nakakakuha ng sagot ang IKE, itinatapon ng patakarang nagpapahintulot lamang ng isang protocol ang naka-encapsulate na tunnel, o nagwawakas ang mapping ng pagsasalin habang idle ang tunnel. Kapag alam mo kung anong yugto ka naroon, ang pagwawasto ay karaniwang isang tuntunin o isang keepalive, hindi bagong disenyo ng VPN.

Ang mito ang maling tanong

Ang kapaki-pakinabang na tanong ay hindi «sinisira ba ito ng NAT» kundi «aling bahagi ng palitan ang isinasalin, at ano ang ginagawa rito ng device na nagsasalin». Ang L2TP/IPsec ay isang layered na protocol: nag-uusap ang IKE, nagpoprotekta ang ESP, at L2TP ay nagdadala ng PPP sa loob ng proteksyong iyon. Iba ang epekto ng pagsasalin ng address sa bawat layer, at nakikilala ang mga tanda ng pagkasira kung titingnan mo ang yugto ng negosasyon kaysa sa dialog ng error.

Ang router na matagumpay na nagba-browse sa web ay nagpapatunay lamang na gumagana ang TCP na may pagsasalin ng source port. Wala itong sinasabi tungkol sa UDP 500, UDP 4500 o protocol 50, at nakasalalay ang deployment na ito sa tatlong iyon.

Yugto 1: kailangang makakuha ng sagot ang IKE

Ang unang palitan ay papunta sa responder sa UDP 500. Kung walang sagot na bumalik, wala nang ibang mahalaga: ang paunang ibinahaging key, ang panukala at ang mga kredensyal ay nananatiling hindi nabasa. Panoorin ang kahilingan at ang sagot sa halip na maghinuha mula sa timeout ng kliyente:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Ang kahilingang walang sagot ay karaniwang nangangahulugang itinatapon ng firewall o ng carrier sa itaas ang packet, hindi na tinanggihan ito ng server. Ang sagot na may notification payload na nagbabanggit ng panukala o problema sa sertipiko ay nangangahulugang dumating ang mga packet at nabigo ang negosasyon sa nilalaman, na isang ganap na ibang pag-aayos.

Kapag ang dalawang panig ay nasa likod ng pagsasalin, kailangan lamang maabot ng nagpasimula ang responder, kaya karamihan ng deployment sa panig ng kliyente ay gumagana mula sa yugto 1. Ang pagho-host sa panig ng server ang pinagsisimulan ng problema sa inbound, at iyon ang dahilan kung bakit hindi dapat pag-usapan ang dalawang sitwasyon bilang isa.

Yugto 2: binabago ng encapsulation ang nakikita ng firewall

Ang ESP ay isang IP protocol, hindi TCP o UDP port, at ang ordinaryong pagsasalin ng address ng port ay walang port field na maisusulat muli. Kaya inililipat ng NAT traversal ang protektadong payload sa UDP 4500: binibigyan ng encapsulation ang device na nagsasalin ng isang bagay na alam nitong isalin. Kapag nangyari iyon, isang tuntunin ng firewall na isinulat lamang para sa UDP 500 ang magpapahintulot sa negosasyon at itatapon ang tunnel, na nagbubunga ng nakalilitong resulta kung saan ang log ay nagpapakita ng matagumpay na phase 1 at walang trapiko.

Ang palitan ng IKE mismo ay maaari ring lumipat sa UDP 4500 pagkatapos matukoy ang NAT, na ikinagugulat ng mga nagpahintulot lamang ng 500. Payagan ang dalawang port sa dalawang direksyon sa landas, at tandaan na ang stateful firewall ay nagpapanatili ng daloy hanggat nakikita nito ang trapiko.

Mahalaga pa rin ang protocol 50 sa mga landas na walang pagsasalin, at sa mga landas kung saan ang intermediate box ay naka-configure na payagan ito. Kung nag-diagnose ka sa pamamagitan ng pag-alis, patayin ang hypothesis sa halip na magdagdag ng mga tuntunin nang bultuhan: payagan ang 500, 4500 at ESP, kumpirmahin na umaangat ang tunnel, pagkatapos ay alisin ang napatunayang hindi kailangan. Ang tuntuning walang makapagpapaliwanag ay tuntuning walang mag-aalis kapag naging sanhi ito ng susunod na pagkaputol. Isulat ang pagpapaliit sa talaan ng pagbabago kasama ang yugtong inayos nito, upang ang susunod na inhinyero ay magsimula sa iyong ebidensya at hindi sa parehong panuntunan.

Yugto 3: nagwawakas ang mapping at namamatay ang tunnel

Ang device na nagsasalin ay nagpapanatili ng estado para sa mga daloy na ipinapasa nito, at may habang-buhay ang estadong iyon. Kaunti lang ang trapikong dinadala ng L2TP/IPsec tunnel kapag walang gumagamit, kaya ang idle na tunnel ay maaaring mabuhay nang mas mahaba kaysa sa mapping nito at tumigil sa pagtanggap ng pabalik na trapiko. Nananatiling kumbinsido ang kliyente na konektado ito, walang nakikita ang server, at ang unang sintomas ay karaniwang timeout ng application at hindi error ng VPN.

Umiiral ang dead peer detection at NAT keepalives para dito, at dapat pumayag ang dalawang dulo na ipadala ang mga ito. Kung ang server mo ay nasa likod ng pagsasalin, ang pangangailangan sa panig ng Windows ay isang dokumentadong setting ng registry na nagpapalagay sa server ng UDP encapsulation para sa sarili nitong outbound packets; kung wala iyon, nagpapadala ang responder ng ESP na hindi maaaring i-map pabalik ng device na nagsasalin. Ito ay isyu ng configuration ng server, hindi ng kliyente.

Ang pagbabago ng WAN address ay nagbubunga ng parehong resulta mula sa ibang direksyon: muling itinatayo ang mapping sa paligid ng bagong address, at ang lumang security association ay tumuturo na ngayon sa tuple na wala na. Ang pag-uugali ng muling pagkonekta ay pag-aari ng implementasyon ng kliyente, at iyon ang dahilan kung bakit «kumonekta muli pagkatapos mag-reboot ang router» ay gumagana sa isang kliyente at nangangailangan ng manu-manong switch sa iba.

Ang pagho-host sa likod ng carrier-grade NAT ay ibang problema

Kung gusto mong i-host ang L2TP/IPsec server sa bahay at maabot ito mula sa labas, ang pangangailangan ay hindi hinihinging inbound na maabot, at hindi iyon ang ibinibigay ng NAT traversal. Ang carrier-grade NAT sa harap ng router mo ay nangangahulugang walang port na maaari mong i-forward na gagawin kang maabot, dahil ang pampublikong address ay ibinabahagi at ang mapping ay outbound lamang.

Walang kahon ng IPsec pass-through ang makakabago niyan, at walang configuration ng kliyente ang makakabawi. Ang mga sinusuportahang sagot ay isang address na talagang maabot, isang naka-host na endpoint, o isang arkitekturang gumagawa ng outbound na koneksyon ang bawat kalahok. Ang espesipikasyon ng UDP encapsulation ay lumulutas sa problema ng pagsasalin para sa mga daloy na umiiral; hindi ito lumilikha ng inbound na landas kung saan walang iniaalok ang carrier.

Kaya ihambing ang mga network sa halip na manghula. Dalhin ang parehong device at profile sa ibang pinapayagang network at tingnan kung aling yugto ang nabibigo doon. Kung gumagana ito sa ibang lugar, ang pagkakaiba ay nasa landas, at pinaliit niyon ang paghahanap sa tatlong yugto sa itaas kaysa sa buong configuration.