Hairpin-NAT: miks VPN-i lõpp-punkt seestpoolt ei tööta

VPN-server, mis vastab mobiilivõrgust, kuid ei tööta diivanilt, ei ole tavaliselt sertifikaadi probleem. LAN-i sees olev klient palub ruuteril tõlkida paketti, mille sihtkohaks on ruuteri enda avalik aadress, mis tähendab, et pakett peab välja minema ja kohe tagasi sisse tulema. Seda manöövrit nimetatakse hairpinninguks ja paljud ruuterid kas ei rakenda seda üldse või teevad seda ainult siis, kui märkeruut on lubatud. Just väljastpoolt tehtud testi õnnestumine teeb asja segaseks, sest see tõestab, et kuulaja ja edastusreegel on korras.

Pakett läheb välja ja tuleb tagasi sisse

Jälgige paketti. Klient lahendab avaliku nime, ühendub avaliku aadressiga ja ruuteri sihtkoha NAT kirjutab sihtkoha ümber sisemisele serverile. Serveri vastus on adresseeritud kliendi LAN-aadressile, seega läheb see ruuteri LAN-liidese kaudu tagasi, läbimata kunagi seda NAT-reeglit, mis oleks allika tagasi tõlkinud.

Nüüd saab klient paketi aadressilt, kuhu ta pole kunagi midagi saatnud, ja viskab selle ära. Kogu rike ongi see asümmeetria.

RFC 4787 kirjeldab käitumist, mida NAT-ilt sellisel juhul oodatakse, ja lühike versioon on, et praktikas on see valikuline ka seal, kus see on teoreetiliselt määratletud. Mõned ruuterid nimetavad seade NAT loopbackiks, teised hairpin NAT-iks või NAT reflectioniks ja mõned ei näita üldse midagi. Ruuter, millel seda pole, ei ole valesti seadistatud; see teeb tavalist asja ja parandus kuulub mujale. Ärge järeldage ebaõnnestunud kohalikust testist, et avalik edastusreegel on vale.

Kontroll 1: testige kahte teed eraldi

Väljastpoolt LAN-i ühenduge sama profiiliga, mida kasutaks päris kasutaja, ja veenduge, et sessioon luuakse. Seestpoolt ühenduge sama profiiliga avaliku aadressiga ja kirjutage üles täpne viga ja kellaaeg.

Täpne kohalik test hoiab alles hostinime ja asendab ainult aadressi: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ saadab päringu avalikule aadressile, esitades samal ajal õige serverinime. See eraldab nimelahenduse probleemi tõlkimise probleemist, mida on lihtne segi ajada, kui sama nimi töötab kohvikust. Pange tähele, kas klient ebaõnnestub TCP-ühendusel või hiljem TLS-is, sest esimene viitab tõlkimisele ja teine identiteedile.

Kontroll 2: lugege, mida server näeb

Kõige kasulikum vaatlus on serveri vaade. Käivitage VPN-hostis jäädvustus, mis on filtreeritud kliendi LAN-aadressile ja ruuteri LAN-aadressile, seejärel korrake kohalikku katset. Kui midagi ei saabu, ei jäänud pakett tõlkimisest ellu.

Kui ühendus saabub ruuteri LAN-aadressilt, mitte kliendi omalt, toimub hairpinning ja allikas kirjutati ümber. See on toimiv konfiguratsioon, mitte rike.

Kontroll 3: parandage see välisele teele puutumata

Olemas on kolm toetatud kuju, mõjuraadiuse kasvavas järjekorras. Kõige kitsam on jagatud DNS: avaldage sisemine kirje, et sama serverinimi lahenduks LAN-is olevatele klientidele sisemiseks aadressiks, mis väldib avalikku teed täielikult. Järgmine on ruuteri dokumenteeritud loopback- või reflection-valiku lubamine, kui see on olemas, ja selle rakendamine ainult sellele teenusele. Kõige laiem on ruuteri source-NAT reegel, mis kirjutab LAN-ist lähtuva liikluse serverile ümber, et vastus tuleks ruuteri kaudu tagasi; Linuxi ruuteril on see MASQUERADE reegel POSTROUTING ahelas, mis vastab serveri aadressile ja pordile. Kõik kolm jätavad välise tee puutumata ja just seda omadust tuleb hoida.

Ärge laiendage mitteseotud pordiedastust, et muuta kohalik tee välisega sarnaseks, ja ärge viige teenust teisele pordile probleemi vältimiseks. Mõlemad muudatused muudavad seda, mida välismaailm kätte saab, et parandada midagi, mida näeb ainult sisemaailm.

Jagatud DNS-il on üks lõks, mida tasub nimetada. Hostinime asendamine suvalise IP-ga muudab seda, mida klient valideerib, seega peab sisemine kirje endiselt sertifikaadi nimega sobima.

Kontroll 4: seejärel kontrollige mõlemat teed

Korrake välist katset väljastpoolt LAN-i, korrake sisemist katset sama profiiliga ja veenduge, et serveri logi näitab kahte eraldi õnnestunud sessiooni, mitte ühte õnnestumist ja ühte vaikust. Seejärel kontrollige, et teised kliendid jõuavad endiselt kuulajani ja et marsruudid privaatsete ressurssideni on muutumatud.

Hoidke kirje lühike: millist aadressi iga klient kasutas, mida server nägi ja millist kolmest parandusest rakendati. RFC 4787 hairpinningu nõuded on siin viide sellele, mida NAT-ilt oodatakse, ja need selgitavad, miks ilma selle funktsioonita ruuter käitub normaalselt. Kohalik tõrge, mida välismaailm korrata ei suuda, on tõlkimise küsimus, kuni pole tõestatud vastupidist, seega testige seda nii.