Hairpin NAT: kāpēc VPN galapunkts nedarbojas no iekšpuses

VPN serveris, kas atbild no mobilā tīkla, bet nedarbojas no dīvāna, parasti nav sertifikāta problēma. Klients LAN iekšienē lūdz maršrutētāju pārtulkot pakešu, kuras mērķis ir paša maršrutētāja publiskā adrese, kas nozīmē, ka pakešu jāiziet ārā un nekavējoties jāatgriežas iekšā. Šis manevrs tiek saukts par hairpinning, un daudzi maršrutētāji to vai nu vispār neievieš, vai dara tikai tad, kad ir atzīmēta izvēles rūtiņa. Tieši veiksmīgais tests no ārpuses rada apjukumu, jo tas pierāda, ka klausītājs un pārsūtīšanas noteikums ir kārtībā.

Pakešu iziet ārā un atgriežas iekšā

Izsekojiet pakešu. Klients atrisina publisko vārdu, savienojas ar publisko adresi, un maršrutētāja galamērķa NAT pārraksta galamērķi uz iekšējo serveri. Servera atbilde ir adresēta klienta LAN adresei, tāpēc tā atgriežas pa maršrutētāja LAN saskarni, nekad nešķērsojot to NAT noteikumu, kas būtu pārtulkojis avotu atpakaļ.

Tagad klients saņem pakešu no adreses, uz kuru nekad neko nav sūtījis, un to izmet. Šī asimetrija ir viss bojājums.

RFC 4787 apraksta uzvedību, kas šajā gadījumā tiek sagaidīta no NAT, un īsā versija ir tāda, ka praksē tā ir neobligāta pat tur, kur teorētiski tā ir noteikta. Daži maršrutētāji šo iestatījumu sauc par NAT loopback, citi par hairpin NAT vai NAT reflection, bet daži neko neparāda. Maršrutētājs, kuram tā nav, nav nepareizi konfigurēts; tas dara parasto lietu, un labojums pieder citur. Neizdariet no neveiksmīga vietējā testa secinājumu, ka publiskais pārsūtīšanas noteikums ir nepareizs.

Pārbaude 1: pārbaudiet abus ceļus atsevišķi

No ārpuses LAN savienojieties ar to pašu profilu, kuru izmantotu īsts lietotājs, un apstipriniet, ka sesija tiek izveidota. No iekšpuses savienojieties ar publisko adresi ar to pašu profilu un pierakstiet precīzu kļūdu un laiku.

Precīzs vietējais tests saglabā resursdatora nosaukumu un aizstāj tikai adresi: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ nosūta pieprasījumu uz publisko adresi, vienlaikus uzrādot pareizo servera nosaukumu. Tas atdala nosaukumu atrisināšanas problēmu no tulkošanas problēmas, kuras ir viegli sajaukt, ja tas pats nosaukums darbojas no kafejnīcas. Ņemiet vērā, vai klients neizdodas TCP savienojuma laikā vai vēlāk TLS, jo pirmais norāda uz tulkošanu, bet otrais uz identitāti.

Pārbaude 2: izlasiet, ko redz serveris

Noderīgākais novērojums ir servera skatījums. Palaidiet ierakstu VPN resursdatorā, filtrētu pēc klienta LAN adreses un maršrutētāja LAN adreses, pēc tam atkārtojiet vietējo mēģinājumu. Ja nekas neienāk, pakešu tulkojumu nav pārcietis.

Ja savienojums nāk no maršrutētāja LAN adreses, nevis no klienta, notiek hairpinning un avots ir pārrakstīts. Tā ir strādājoša konfigurācija, nevis bojājums.

Pārbaude 3: salabojiet, neaiztiekot ārējo ceļu

Pastāv trīs atbalstītas formas, pieaugošā ietekmes rādiusa secībā. Šaurākā ir sadalītais DNS: publicējiet iekšēju ierakstu, lai tas pats servera nosaukums LAN klientiem atrisinātos uz iekšējo adresi, kas pilnībā izvairās no publiskā ceļa. Nākamā ir iespējot maršrutētāja dokumentēto loopback vai reflection opciju, ja tāda ir, un piemērot to tikai šim servisam. Plašākā ir source-NAT noteikums maršrutētājā, kas pārraksta no LAN nākošo satiksmi uz serveri, lai atbilde atgrieztos caur maršrutētāju; Linux maršrutētājā tas ir MASQUERADE noteikums POSTROUTING ķēdē, kas atbilst servera adresei un portam. Visas trīs atstāj ārējo ceļu neskartu, un tā ir īpašība, kas jāsaglabā.

Nepaplašiniet nesaistītu portu pārsūtīšanu, lai vietējais ceļš līdzinātos ārējam, un nepārvietojiet servisu uz citu portu, lai izvairītos no problēmas. Abas izmaiņas maina to, ko var sasniegt ārējā pasaule, lai salabotu kaut ko tādu, ko redz tikai iekšējā.

Sadalītajam DNS ir viens slazds, ko ir vērts nosaukt. Resursdatora nosaukuma aizstāšana ar patvaļīgu IP maina to, ko klients validē, tāpēc iekšējam ierakstam joprojām jāatbilst sertifikāta nosaukumam.

Pārbaude 4: pēc tam pārbaudiet abus ceļus

Atkārtojiet ārējo mēģinājumu no ārpuses LAN, atkārtojiet iekšējo mēģinājumu ar to pašu profilu un apstipriniet, ka servera žurnāls rāda divas atsevišķas veiksmīgas sesijas, nevis vienu panākumu un vienu klusumu. Pēc tam pārbaudiet, vai citi klienti joprojām sasniedz klausītāju un vai maršruti uz privātiem resursiem nav mainījušies.

Turiet ierakstu īsu: kuru adresi izmantoja katrs klients, ko redzēja serveris un kura no trim labojumiem tika piemērota. RFC 4787 hairpinning prasības šeit ir atsauce uz to, ko no NAT sagaida, un tās izskaidro, kāpēc maršrutētājs bez šīs funkcijas uzvedas normāli. Vietēja kļūme, ko ārējā pasaule nevar atkārtot, ir tulkošanas jautājums, līdz tiek pierādīts pretējais, tāpēc pārbaudiet to kā tādu.