L2TP/IPsec tra NAT: kio vere rompiĝas kaj kial

La aserto, ke NAT rompas L2TP/IPsec, estas duone vera kaj tial senutila. Adres-tradukado estas normala, NAT-trairejo ekzistas ĝuste por postvivi ĝin, kaj milionoj da klientoj konektiĝas ĉiutage malantaŭ enkursigilo. Tio, kio rompiĝas, estas specifa etapo de specifa interŝanĝo: IKE neniam ricevas respondon, la enkapsuligita tunelo estas forĵetata de politiko, kiu permesas nur unu protokolon, aŭ la traduka mapado eksvalidiĝas dum la tunelo estas neaktiva. Kiam vi scias, en kiu etapo vi estas, la riparo estas kutime unu regulo aŭ keepalive, ne nova VPN-dezajno.

La mito estas la malĝusta demando

La utila demando ne estas «ĉu NAT rompas tion», sed «kiu parto de la interŝanĝo tradukiĝas, kaj kion faras kun ĝi la aparato, kiu tradukas». L2TP/IPsec estas tavolita protokolo: IKE intertraktas, ESP protektas, kaj L2TP portas PPP ene de tiu protekto. Adres-tradukado interagas malsame kun ĉiu tavolo, kaj la malsukcesaj subskriboj distingeblas, se vi rigardas la intertraktan etapon anstataŭ la eraran dialogon.

Enkursigilo, kiu sukcese retumas, pruvas nur, ke TCP kun fonta porda tradukado funkcias. Ĝi diras nenion pri UDP 500, UDP 4500 aŭ protokolo 50, kaj ĝuste de tiuj tri aferoj dependas ĉi tiu deplojo.

Etapo 1: IKE devas entute ricevi respondon

La unua interŝanĝo iras al la respondanto ĉe UDP 500. Se neniu respondo revenas, nenio alia gravas: la antaŭe kunhavigita ŝlosilo, la propono kaj la akreditaĵoj restas nelegitaj. Observu la peton kaj la respondon anstataŭ konkludi el la tempolimo de la kliento:

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

Peto sen respondo kutime signifas, ke fajroŝirmilo aŭ la supra operatoro forĵetas la paketon, ne ke la servilo rifuzis ĝin. Respondo kun sciiga utilŝarĝo, kiu nomas proponon aŭ atestilan problemon, signifas, ke la paketoj alvenis kaj la intertraktado malsukcesis pro enhavo, kio estas tute alia riparo.

Kiam ambaŭ flankoj sidas malantaŭ tradukado, la iniciatinto devas nur atingi la respondanton, do la plej multaj klientflankaj deplojoj funkcias de etapo 1. Servila gastigado estas kie komenciĝas la enira problemo, kaj tial la du situacioj neniam diskutu kiel unu.

Etapo 2: enkapsuligo ŝanĝas tion, kion vidas la fajroŝirmilo

ESP estas IP-protokolo, ne TCP- aŭ UDP-pordo, kaj ordinara porda adres-tradukado ne havas pordan kampon por reskribi. Tial NAT-trairejo movas la protektitan utilŝarĝon en UDP 4500: la enkapsuligo donas al la tradukanta aparato ion, kion ĝi scias traduki. Post kiam tio okazas, fajroŝirmila regulo skribita nur por UDP 500 permesas la intertraktadon kaj forĵetas la tunelon, kio produktas la konfuzan rezulton, kie la protokolo montras sukcesan fazon 1 kaj neniun trafikon.

La IKE-interŝanĝo mem ankaŭ povas moviĝi al UDP 4500 post kiam NAT estas detektita, kio surprizas homojn, kiuj permesis 500 kaj nenion alian. Permesu ambaŭ pordojn en ambaŭ direktoj sur la vojo, kaj memoru, ke stata fajroŝirmilo povas teni la fluon nur dum ĝi vidas trafikon.

Protokolo 50 ankoraŭ gravas sur vojoj sen tradukado, kaj sur vojoj, kie meza skatolo estas agordita por permesi ĝin. Se vi diagnozas per eliminado, malŝaltu la hipotezon anstataŭ aldoni regulojn amase: permesu 500, 4500 kaj ESP, konfirmu, ke la tunelo leviĝas, poste forigu tion, kio montriĝis nenecesa. Regulo, kiun neniu povas klarigi, estas regulo, kiun neniu forigos, kiam ĝi fariĝos la kaŭzo de la sekva interrompo. Skribu la mallarĝigon en la ŝanĝprotokolon kune kun la etapo, kiun ĝi riparis, por ke la sekva inĝeniero komencu de viaj pruvoj anstataŭ de la sama sperta regulo.

Etapo 3: la mapado eksvalidiĝas kaj la tunelo mortas

Tradukanta aparato tenas staton por la fluoj, kiujn ĝi plusendas, kaj tiu stato havas vivdaŭron. L2TP/IPsec-tunelo portas malmulte da trafiko, kiam neniu uzas ĝin, do neaktiva tunelo povas postvivi sian mapadon kaj ĉesi ricevi returtrafikon. La kliento restas konvinkita, ke ĝi estas konektita, la servilo vidas nenion, kaj la unua simptomo kutime estas aplikaĵa tempolimo, ne VPN-eraro.

Detektado de mortinta partnero kaj NAT-keepalive ekzistas por tio, kaj ambaŭ finoj devas esti pretaj sendi ilin. Se via servilo estas malantaŭ tradukado, la postulo ĉe Windows estas dokumentita registra agordo, kiu igas la servilon supozi UDP-enkapsuligon por siaj propraj eliraj paketoj; sen ĝi la respondanto sendas ESP, kiun la tradukanta aparato ne povas remapi. Tio estas servila agorda afero, ne klienta.

Ŝanĝo de WAN-adreso produktas la saman rezulton el alia direkto: la mapado rekonstruiĝas ĉirkaŭ nova adreso, kaj la malnova sekureca asocio nun montras al opo, kiu ne plu ekzistas. Rekonekta konduto apartenas al la klienta efektivigo, kaj tial «rekonekti post la restartigo de la enkursigilo» funkcias ĉe unu kliento kaj bezonas manan ŝaltilon ĉe alia.

Gastigado malantaŭ operator-grada NAT estas alia problemo

Se vi volas gastigi L2TP/IPsec-servilon hejme kaj atingi ĝin de ekstere, la postulo estas nepetita enira atingeblo, kaj tio ne estas, kion NAT-trairejo provizas. Operator-grada NAT antaŭ via enkursigilo signifas, ke ekzistas neniu pordo, kiun vi povas plusendi kaj igi vin atingebla, ĉar la publika adreso estas kunhavigita kaj la mapado estas nur elira.

Neniu IPsec pass-through-markobutono ŝanĝas tion, kaj neniu kvanto da klienta agordo kompensas ĝin. La subtenataj respondoj estas adreso, kiu estas vere atingebla, gastigita finpunkto, aŭ arkitekturo, kie ĉiu partoprenanto faras eliran konekton. La UDP-enkapsuliga specifikaĵo solvas la tradukan problemon por fluoj, kiuj ekzistas; ĝi ne kreas eniran vojon, kie la operatoro ne proponas unu.

Do komparu retojn anstataŭ diveni. Prenu la saman aparaton kaj profilon al alia permesita reto kaj observu, kiu etapo malsukcesas tie. Se ĝi funkcias aliloke, la diferenco estas en la vojo, kaj tio mallarĝigas la serĉon al la tri etapoj supre anstataŭ al la tuta agordo.