Hairpin NAT: bakit nabigo ang VPN endpoint mula sa loob

Ang VPN server na sumasagot mula sa mobile network ngunit nabigo mula sa sopa ay karaniwang hindi problema sa sertipiko. Hinihiling ng kliyente sa loob ng LAN sa router na isalin ang isang packet na ang destinasyon ay ang sariling pampublikong address ng router, ibig sabihin, dapat lumabas ang packet at agad na pumasok muli. Ang manobrang iyon ay tinatawag na hairpinning, at maraming router ang alinman sa hindi ito ipinapatupad o ginagawa lamang kapag naka-enable ang isang checkbox. Ang pagpasa ng pagsubok mula sa labas ang dahilan ng kalituhan, dahil pinapatunayan nitong maayos ang listener at ang tuntunin ng pagpapasa.

Lumalabas ang packet at pumapasok muli

Sundan ang packet. Nilulutas ng kliyente ang pampublikong pangalan, kumokonekta sa pampublikong address, at isinusulat muli ng destination NAT ng router ang destinasyon patungo sa panloob na server. Ang sagot ng server ay naka-address sa LAN address ng kliyente, kaya bumabalik ito sa pamamagitan ng LAN interface ng router nang hindi kailanman dumadaan sa NAT rule na sana ay nagbalik-translate sa source.

Ngayon ay tumatanggap ang kliyente ng packet mula sa isang address na hindi nito kailanman pinadalhan ng anuman, at itinatapon ito. Ang kawalan ng simetrya na iyon ang buong sira.

Inilalarawan ng RFC 4787 ang inaasahang pag-uugali ng NAT sa kasong ito, at ang maikling bersyon ay opsyonal ito sa pagsasagawa kahit saan man ito tinukoy sa teorya. Tinatawag ng ilang router ang setting na NAT loopback, tinatawag ito ng iba na hairpin NAT o NAT reflection, at may ilang walang ipinapakita. Ang router na wala nito ay hindi mali ang pagkaka-configure; ginagawa nito ang karaniwang bagay, at sa ibang lugar nararapat ang pagwawasto. Huwag maghinuha mula sa bigong lokal na pagsubok na mali ang pampublikong tuntunin ng pagpapasa.

Pagsusuri 1: subukan ang dalawang landas nang hiwalay

Mula sa labas ng LAN, kumonekta gamit ang parehong profile na gagamitin ng totoong user at kumpirmahin na nabuo ang session. Mula sa loob, kumonekta sa pampublikong address gamit ang parehong profile at itala ang eksaktong error at oras.

Ang tumpak na lokal na pagsubok ay nagpapanatili ng hostname at pinapalitan lamang ang address: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ ipinapadala ang kahilingan sa pampublikong address habang ipinapakita pa rin ang tamang pangalan ng server. Hinihiwalay nito ang problema sa paglutas ng pangalan mula sa problema sa pagsasalin, na madaling mapagkamalan kapag gumagana ang parehong pangalan mula sa isang kapihan. Tandaan kung nabigo ang kliyente sa TCP connection o mamaya sa TLS, dahil ang una ay tumutukoy sa pagsasalin at ang pangalawa sa pagkakakilanlan.

Pagsusuri 2: basahin ang nakikita ng server

Ang pinakakapaki-pakinabang na obserbasyon ay ang pananaw ng server. Magpatakbo ng capture sa VPN host na sinasala sa LAN address ng kliyente at sa LAN address ng router, pagkatapos ay ulitin ang lokal na pagtatangka. Kung walang dumarating, hindi nakaligtas ang packet sa pagsasalin.

Kung ang koneksyon ay dumarating mula sa LAN address ng router sa halip na sa address ng kliyente, nagaganap ang hairpinning at muling isinulat ang source. Ito ay gumaganang configuration, hindi depekto.

Pagsusuri 3: ayusin nang hindi hinahawakan ang panlabas na landas

May tatlong sinusuportahang anyo, sa pagtaas ng lawak ng epekto. Ang pinakamakitid ay split DNS: maglathala ng panloob na record upang ang parehong pangalan ng server ay malutas sa panloob na address para sa mga kliyente sa LAN, na lubos na umiiwas sa pampublikong landas. Ang susunod ay ang pagpapagana ng dokumentadong loopback o reflection na opsyon ng router, kung mayroon, at paglalapat nito sa serbisyong ito lamang. Ang pinakamalawak ay isang source-NAT rule sa router na muling nagsusulat ng trapiko mula sa LAN patungo sa server upang ang sagot ay bumalik sa pamamagitan ng router; sa isang Linux router ito ay isang MASQUERADE rule sa POSTROUTING na tumutugma sa address at port ng server. Ang tatlo ay nag-iiwan sa panlabas na landas na hindi ginalaw, at iyon ang katangiang dapat panatilihin.

Huwag palawakin ang walang kaugnayang port forwarding upang maging katulad ng panlabas ang lokal na landas, at huwag ilipat ang serbisyo sa ibang port upang iwasan ang problema. Ang parehong pagbabago ay nagbabago kung ano ang maaabot ng labas na mundo upang ayusin ang isang bagay na tanging loob na mundo ang nakakakita.

Ang split DNS ay may isang bitag na dapat banggitin. Ang pagpapalit ng hostname ng arbitraryong IP ay nagbabago kung ano ang bineberipika ng kliyente, kaya ang panloob na record ay dapat pa ring tumugma sa pangalan sa sertipiko.

Pagsusuri 4: beripikahin ang parehong landas pagkatapos

Ulitin ang panlabas na pagtatangka mula sa labas ng LAN, ulitin ang panloob na pagtatangka gamit ang parehong profile, at kumpirmahin na ang log ng server ay nagpapakita ng dalawang magkaibang matagumpay na session at hindi isang tagumpay at isang katahimikan. Pagkatapos ay tiyakin na ang ibang mga kliyente ay umaabot pa rin sa listener at ang mga ruta sa pribadong mapagkukunan ay hindi nagbago.

Panatilihing maikli ang tala: aling address ang ginamit ng bawat kliyente, ano ang nakita ng server, at alin sa tatlong pagwawasto ang inilapat. Ang mga kinakailangan sa hairpinning ng RFC 4787 ang sanggunian para sa inaasahan mula sa NAT dito, at ipinapaliwanag nila kung bakit normal ang pag-uugali ng router na walang tampok na ito. Ang lokal na kabiguan na hindi maaaring kopyahin ng labas na mundo ay isang tanong sa pagsasalin hanggang mapatunayang salungat, kaya subukan ito nang ganoon.