Kā OpenVPN klients aiz NAT kļūst par interneta izeju

Trīs Linux resursdatori, viens risinājums: publiski sasniedzams OpenVPN centrs, lietotāja portatīvais dators un izejas mašīna aiz parasta mājas maršrutētāja, kas neko nepārsūta uz iekšu. Izeja pati zvana uz centru. Tad lietotāja interneta trafiks portatīvajā datorā ieiet tunelī un iziet caur pašas izejas augšupējo saiti. Viss pārsteidzošais šajā izkārtojumā izriet no vienas detaļas: savienojumu sāka izeja, tāpēc ceļš uz iekšu jau pastāv un tā izveidei nav vajadzīga portu pāradresācija.

Turpmāk tiek sekots pakešu ceļam, nevis konfigurācijas secībai, jo konfigurācijai ir jēga tikai tad, kad zina, kura komponente pieņem kuru lēmumu. Katrs slānis pieņem tieši vienu lēmumu, un kļūdas sakrājas tur, kur divi slāņi tiek uzskatīti par vienu.

Divas transporta sesijas, viens iekšējs ceļš

Katrs resursdators uztur savu ārējo savienojumu ar centru, un neviens no šiem savienojumiem nezina par otru. Lietotāja trafiks uz internetu ir atsevišķa iekšēja plūsma, kas tiek pārnesta lietotāja tunelī un pēc tam atkal izlaista no izejas tuneļa. Tieši šī iekšējā plūsma centram ir jāmaršrutē, un izejai tā ir jāpārsūta.

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

Tā kā abi ārējie savienojumi nāk no klienta puses uz āru, izejas maršrutētājs nekad neredz ienākošu SYN un nekad neprasa galamērķa NAT noteikumu. Tam tikai jāuztur izveidotais transports dzīvs, ko tas jau dara jebkuram ilgstošam savienojumam. Nekam publiskajā internetā nav vispirms jāsasniedz izeja, tāpēc dinamiska adrese šajā augšupējā saitē nav problēma. Maršrutētājam tomēr jāatļauj izejošā sesija, bet tā ir tā pati atļauja, ko pārlūkprogramma jau izmanto.

Ko iroute patiešām instalē serverī

Centrs ir vienīgā ierīce, kas izlemj, kuram partnerim pieder kurš galamērķis, un šo lēmumu pieņem savā lietotāja telpas maršrutēšanas tabulā, nevis kodola. Ieraksts client-config-dir izejai ar nosaukumu exit-node var tur pieprasīt noklusējuma prefiksu:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

Šī rinda saka servera procesam "iekšējie paketes ar jebkuru galamērķi pieder šim klientam". Tā nepievieno noklusējuma maršrutu centra operētājsistēmai un nepadara centru par interneta vārteju. OpenVPN 2.6 rokasgrāmata uztur klientam raksturīgo iekšējo maršrutēšanu un kodola maršrutēšanu kā atsevišķus mehānismus, un tieši šī atdalīšana ir iemesls, kāpēc risinājums darbojas, neaiztiekot centra noklusējuma maršrutu.

Lietotājam vajadzīga spoguļa instrukcija, kas piegādāta kā push, lai viņa trafiks iekļūtu tunelī, nevis izietu caur vietējo vārteju. Apakštīkla topoloģijā pūls ir pievienots maršruts izejas tun ierīcē, tāpēc atgriešanās virzienam nav vajadzīgs papildu push; tas, ko izeja nedrīkst saņemt, ir zemāk redzamā novirzīšana, kas nosūtītu tās pašas augšupējo trafiku atpakaļ tunelī, kuru tā cenšas izmantot. Sūtiet to tikai lietotājam un lasiet lietotos maršrutus klientā, nevis paļaujieties, ka CCD fails tika izvēlēts.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

Pārsūtīšanu veic izejas kodols

Izejas iekšienē pakete no lietotāja ierodas tun saskarnē, adresēta kādam interneta resursdatoram. Kodols apskata savu maršrutēšanas tabulu, atrod īsto augšupējo saiti kā labāko atbilstību un pēc tam piemēro divas neatkarīgas politikas: vai šo pakešu vispār drīkst pārsūtīt un vai tā drīkst iziet pa šo saskarni ar šo avota adresi. Pārsūtīšana ir sysctl, un daudzās distribūcijās tā pēc noklusējuma ir izslēgta.

Tāpēc izejai vajadzīga pastāvīgi ieslēgta IPv4 pārsūtīšana, noteikums, kas ielaiž lietotāja tuneļa avotus pretī augšupējai saitei, un atbildes ceļš atpakaļ pa tun. Pārsūtīšanas ieslēgšana visam resursdatoram maina arī visa cita uzvedību, kas tiek maršrutēts caur to, tāpēc noteikumam jānosauc avoti un saskarnes, nevis jāpieņem viss.

Atgriešanās ceļu nopērk avota tulkošana

Interneta resursdatoram nav maršruta uz 10.90.0.x adresi, tāpēc atbildes tiktu izmestas, pirms tās vispār sasniegtu izeju. Avota pārrakstīšana, pakešu atstājot augšupējo saiti, to atrisina, un savienojumu izsekošana atgriežoties pārrakstījumu apgriež.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

Iepriekš minētais noteikums ir sākumpunkts vienai augšupējai saskarnei, nevis ugunsmūra politika. Sašauriniet avotu līdz tām piešķirēm, kuras patiešām autorizējāt, un turiet izejas pašas ievades politiku atsevišķi, lai tuneļa trafika maskēšana klusi neatklātu vietējos pakalpojumus. Resursdatorā ar dinamisku augšupējo adresi maskēšana ietaupa arī adreses manuālu izsekošanu.

Kur centrs var noteikt un kur ne

Ar client-to-client un tradicionālo lietotāja telpas datu ceļu centrs nodod iekšējās paketes starp partneriem servera procesa iekšienē. Tās nekad nešķērso centra kodola FORWARD ķēdi, tāpēc kodola noteikums tur nevar ierobežot pārvietošanos starp partneriem, lai cik rūpīgi tas būtu rakstīts. Noteikšanai jādzīvo paša servera politikā: kam drīkst pievienoties, kuru CCD failu viņš saņem un vai vispār tiek piešķirta izejas noklusējuma piederība.

Tāpēc noklusējuma iroute ir plašs uzticēšanās lēmums. Izejai likumīgi jāpieņem atgriezeniskais trafiks no patvaļīgām interneta adresēm, un tai jābūt mašīnai, ko jūs kontrolējat, labojat un uzraugāt. Piešķirt to pašu piederību partnerim, kuram jūs neuzticētu maršrutētāju ir kļūda, uz kuru šis risinājums aicina.

Dalība ir īstā kontrole. Jebkurš klients, kas spēj konfigurēt savus maršrutus, var mēģināt izmantot izeju, tāpēc ierobežojums, kas drīkst pievienoties vai kuriem partneriem izeja kalpos, ir risinājuma daļa, nevis vēlāka doma.

Droši neizdoties, kad izeja pazūd

Izslēdziet izeju, un iekšējā noklusējuma piederība pazūd kopā ar tās sesiju. Tam nevajadzētu notikt, ka centrs klusi kļūst par aizvietojošo izeju: nekāda noklusējuma maršruta no VPN pūla uz centra augšupējo saiti un nekāda plaša maskēšanas noteikuma centrā, kas labprāt pārsūtītu to pašu trafiku. Pārbaudiet šo kļūmi apzināti un pēc tam pārbaudiet atjaunošanos ar svaigu plūsmu, nevis ar jau atvērtu lapu.

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Ja lietotāja trafiks joprojām sasniedz internetu pēc tam, kad izeja ir pazudusi, to pārnēsā kaut kas cits un paredzētās robežas nav. Izmantojiet DNS un IPv6 arī kā atsevišķus lēmumus: IPv4 maršruts plus maskēšana neko nepasaka par AAAA trafiku, un centra virzītais risinātājs atbildēs no vietas, kur vaicājums patiešām iziet.