NAT hairpin: pse pika fundore e VPN dështon nga brenda

Një server VPN që përgjigjet nga një rrjet celular, por dështon nga divani, zakonisht nuk është problem certifikate. Klienti brenda LAN-it i kërkon routerit të përkthejë një paketë destinacioni i së cilës është adresa publike e vetë routerit, që do të thotë se paketa duhet të dalë dhe të kthehet menjëherë brenda. Ky manovër quhet hairpinning, dhe shumë router ose nuk e zbatojnë ose e bëjnë vetëm kur aktivizohet një kuti kontrolli. Është pikërisht suksesi i testit nga jashtë ai që e bën çështjen konfuze, sepse provon që dëgjuesi dhe rregulli i përcjelljes janë në rregull.

Paketa del dhe kthehet brenda

Ndiqni paketën. Klienti zgjidh emrin publik, lidhet me adresën publike, dhe NAT-i i destinacionit të routerit rishkruan destinacionin drejt serverit të brendshëm. Përgjigja e serverit është adresuar drejt adresës LAN të klientit, prandaj kthehet përmes ndërfaqes LAN të routerit pa kaluar kurrë përmes rregullit NAT që do ta kthente burimin.

Tani klienti merr një paketë nga një adresë ku nuk ka dërguar kurrë asgjë, dhe e hedh atë. Kjo asimetri është e gjithë defekti.

RFC 4787 përshkruan sjelljen që pritet nga një NAT në këtë rast, dhe versioni i shkurtër është se në praktikë është opsionale edhe atje ku është përcaktuar teorikisht. Disa router e quajnë cilësimin NAT loopback, të tjerë e quajnë hairpin NAT ose NAT reflection, dhe disa nuk shfaqin asgjë. Një router që nuk e ka nuk është konfiguruar gabimisht; bën gjënë e zakonshme, dhe rregullimi i takon një vendi tjetër. Mos nxirrni nga një test lokal i dështuar përfundimin se rregulli publik i përcjelljes është i gabuar.

Kontrolli 1: testoni dy rrugët ndaras

Nga jashtë LAN-it, lidhuni me të njëjtin profil që do të përdorte një përdorues real dhe konfirmoni se sesioni krijohet. Nga brenda, lidhuni me adresën publike me të njëjtin profil dhe shënoni gabimin e saktë dhe kohën.

Një test lokal i saktë mban emrin e hostit dhe zëvendëson vetëm adresën: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ dërgon kërkesën drejt adresës publike duke paraqitur ende emrin e saktë të serverit. Kjo ndan problemin e zgjidhjes së emrave nga problemi i përkthimit, të cilët ngatërrohen lehtë kur i njëjti emër funksionon nga një kafene. Vini re nëse klienti dështon në lidhjen TCP apo më vonë në TLS, sepse i pari tregon përkthimin dhe i dyti identitetin.

Kontrolli 2: lexoni çfarë sheh serveri

Vëzhgimi më i dobishëm është këndvështrimi i serverit. Ekzekutoni një kapje në hostin VPN të filtruar sipas adresës LAN të klientit dhe sipas adresës LAN të routerit, pastaj përsëritni përpjekjen lokale. Nëse nuk arrin asgjë, paketa nuk i mbijetoi përkthimit.

Nëse një lidhje arrin nga adresa LAN e routerit në vend të asaj të klientit, po ndodh hairpinning dhe burimi u rishkrua. Ky është një konfigurim që funksionon, jo një defekt.

Kontrolli 3: rregullojeni pa prekur rrugën e jashtme

Ekzistojnë tre forma të mbështetura, sipas rrezes në rritje të ndikimit. Më e ngushta është DNS i ndarë: publikoni një regjistrim të brendshëm që i njëjti emër serveri të zgjidhet në adresën e brendshme për klientët në LAN, çka shmang plotësisht rrugën publike. Tjetra është aktivizimi i opsionit të dokumentuar loopback ose reflection të routerit, nëse e ka, dhe zbatimi i tij vetëm për këtë shërbim. Më e gjera është një rregull source-NAT në router që rishkruan trafikun nga LAN-i drejt serverit, që përgjigja të kthehet përmes routerit; në një router Linux është një rregull MASQUERADE në POSTROUTING që përputhet me adresën dhe portin e serverit. Të tre e lënë rrugën e jashtme të paprekur, dhe kjo është vetia që duhet ruajtur.

Mos zgjeroni përcjelljen e porteve të palidhur për ta bërë rrugën lokale të ngjajë me të jashtmen, dhe mos e zhvendosni shërbimin në një port tjetër për të shmangur problemin. Të dyja ndryshimet ndryshojnë çfarë mund të arrijë bota e jashtme, për të rregulluar diçka që e sheh vetëm bota e brendshme.

DNS i ndarë ka një kurth që ia vlen të përmendet. Zëvendësimi i emrit të hostit me një IP arbitrare ndryshon çfarë validon klienti, prandaj regjistrimi i brendshëm duhet të përputhet ende me emrin në certifikatë.

Kontrolli 4: verifikoni të dyja rrugët më pas

Përsëritni përpjekjen e jashtme nga jashtë LAN-it, përsëritni përpjekjen e brendshme me të njëjtin profil, dhe konfirmoni që regjistri i serverit tregon dy sesione të suksesshme të ndara, jo një sukses dhe një heshtje. Pastaj kontrolloni që klientët e tjerë arrijnë ende dëgjuesin dhe që rrugët drejt burimeve private nuk kanë ndryshuar.

Mbajeni shënimin të shkurtër: cilën adresë përdori çdo klient, çfarë pa serveri dhe cila nga tre rregullimet u zbatua. Kërkesat e hairpinning-ut të RFC 4787 janë referenca për atë që pritet nga një NAT këtu, dhe shpjegojnë pse një router pa këtë veçori sillet normalisht. Një dështim lokal që bota e jashtme nuk mund ta riprodhojë është çështje përkthimi derisa të provohet e kundërta, prandaj testojeni si të tillë.