Hairpin NAT: kial la VPN-finpunkto malsukcesas de interne

VPN-servilo, kiu respondas el poŝtelefona reto kaj malsukcesas el la sofo, kutime ne estas atestila problemo. La kliento ene de la LAN petas al la enkursigilo traduki pakaĵon, kies celo estas la propra publika adreso de la enkursigilo, kio signifas, ke la pakaĵo devas eliri kaj tuj reveni enen. Tiu manovro nomiĝas hairpinning, kaj multaj enkursigiloj aŭ tute ne realigas ĝin aŭ nur kiam markobutono estas ŝaltita. Ĝuste tio, ke la ekstera testo sukcesas, malfaciligas la komprenon, ĉar ĝi pruvas, ke la aŭskultanto kaj la plusenda regulo estas bonaj.

La pakaĵo eliras kaj revenas enen

Spuru la pakaĵon. La kliento solvas la publikan nomon, konektiĝas al la publika adreso, kaj la celloka NAT de la enkursigilo reskribas la celon al la interna servilo. La respondo de la servilo estas adresita al la LAN-adreso de la kliento, do ĝi revenas tra la LAN-interfaco de la enkursigilo, neniam trapasante la NAT-regulon, kiu estus retradukinta la fonton.

Nun la kliento ricevas pakaĵon de adreso, al kiu ĝi neniam sendis ion, kaj forĵetas ĝin. Tiu malsimetrio estas la tuta difekto.

RFC 4787 priskribas la konduton, kiun oni atendas de NAT en ĉi tiu kazo, kaj la mallonga versio estas, ke ĝi praktike estas laŭvola eĉ tie, kie ĝi estas teorie specifita. Kelkaj enkursigiloj nomas la agordon NAT loopback, aliaj nomas ĝin hairpin NAT aŭ NAT reflection, kaj kelkaj tute ne montras ion. Enkursigilo sen ĝi ne estas misagordita; ĝi faras la ordinaran aferon, kaj la riparo apartenas aliloke. Ne konkludu el malsukcesa loka testo, ke la publika plusenda regulo estas malĝusta.

Kontrolo 1: testu la du vojojn aparte

De ekster la LAN, konektiĝu per la sama profilo, kiun uzus reala uzanto, kaj konfirmu, ke la sesio establiĝas. De interne, konektiĝu al la publika adreso per la sama profilo kaj notu la precizan eraron kaj la horon.

Preciza loka testo konservas la gastigantan nomon kaj anstataŭigas nur la adreson: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ sendas la peton al la publika adreso, samtempe prezentante la ĝustan servilan nomon. Tio apartigas nom-solvan problemon disde traduka problemo, kiuj facile konfuziĝas, kiam la sama nomo funkcias el kafejo. Notu, ĉu la kliento malsukcesas ĉe TCP-konekto aŭ poste ĉe TLS, ĉar la unua montras tradukon kaj la dua identecon.

Kontrolo 2: legu, kion vidas la servilo

La plej utila observado estas la vidpunkto de la servilo. Rulu kaptadon sur la VPN-gastiganto filtritan laŭ la LAN-adreso de la kliento kaj laŭ la LAN-adreso de la enkursigilo, poste ripetu la lokan provon. Se nenio alvenas, la pakaĵo ne postvivis la tradukon.

Se konekto alvenas de la LAN-adreso de la enkursigilo anstataŭ de tiu de la kliento, hairpinning okazas kaj la fonto estis reskribita. Tio estas funkcianta agordo, ne difekto.

Kontrolo 3: riparu ĝin sen tuŝi la eksteran vojon

Ekzistas tri subtenataj formoj, laŭ kreskanta amplekso de efiko. La plej mallarĝa estas dividita DNS: publikigu internan rikordon, por ke la sama servila nomo solviĝu al la interna adreso por klientoj en la LAN, kio tute evitas la publikan vojon. La sekva estas ŝalti la dokumentitan opcion loopback aŭ reflection de la enkursigilo, se ĝi havas ĝin, kaj apliki ĝin nur al ĉi tiu servo. La plej larĝa estas source-NAT-regulo sur la enkursigilo, kiu reskribas trafikon el la LAN al la servilo, por ke la respondo revenu tra la enkursigilo; sur Linux-enkursigilo tio estas regulo MASQUERADE en POSTROUTING kongruanta kun la adreso kaj pordo de la servilo. Ĉiuj tri lasas la eksteran vojon netuŝita, kaj tio estas la eco konservenda.

Ne vastigu nerilatan pordan plusendadon por igi la lokan vojon simila al la ekstera, kaj ne movu la servon al alia pordo por eviti la problemon. Ambaŭ ŝanĝoj modifas, kion la ekstera mondo povas atingi, por ripari ion, kion vidas nur la interna mondo.

Dividita DNS havas unu kaptilon indan je mencio. Anstataŭigi gastigantan nomon per arbitra IP ŝanĝas, kion la kliento validigas, do la interna rikordo ankoraŭ devas kongrui kun la nomo en la atestilo.

Kontrolo 4: poste kontrolu ambaŭ vojojn

Ripetu la eksteran provon de ekster la LAN, ripetu la internan provon per la sama profilo, kaj konfirmu, ke la servila protokolo montras du apartajn sukcesajn sesiojn anstataŭ unu sukceso kaj unu silento. Poste kontrolu, ke aliaj klientoj ankoraŭ atingas la aŭskultanton kaj ke la vojoj al privataj rimedoj ne ŝanĝiĝis.

Tenu la rikordon mallonga: kiun adreson uzis ĉiu kliento, kion vidis la servilo, kaj kiun el la tri riparoj oni aplikis. La hairpinning-postuloj de RFC 4787 estas la referenco por tio, kion oni atendas de NAT ĉi tie, kaj ili klarigas, kial enkursigilo sen la funkcio kondutas normale. Loka malsukceso, kiun la ekstera mondo ne povas reprodukti, estas traduka demando ĝis la malo estas pruvita, do testu ĝin kiel tian.