VPN vārteja uz Raspberry Pi: viena tīkla karte vai atsevišķs klienta ports

Jums ir viens Pi, viens strādājošs izejošs VPN profils un divas ierīces, kurām vajadzētu sasniegt internetu caur to. Jautājums, kas nosaka visu uzbūvi, nav par to, kurai pamācībai sekot, bet gan par to, cik daudz norobežošanas jums vajag. Viens ports ļauj Pi stāvēt blakus šīm ierīcēm maršrutētāja LAN tīklā un darboties kā papildu vārteja; otrs ports ļauj tās ievietot segmentā, kur Pi ir vienīgā izeja. Viss pēc šīs izvēles — DHCP, ugunsmūra apjoms, DNS, pārtraukuma gadījums — izriet no tā.

Ar ko abi izkārtojumi patiešām atšķiras

Abi projekti maršrutē. Atšķirība ir tajā, kas vēl stāv uz kabeļa un kas notiek, kad jūsu politika ir nepareiza.

Norobežošana ir īstā ass. Izkārtojums A ir konsultatīvs: ierīce, kas ignorē DHCP piešķirto vārteju un izvēlas maršrutētāju, joprojām darbojas, bet bez šifrēšanas. Izkārtojums B tiek panākts ar topoloģiju, jo nav cita nākamā lēciena, ko izvēlēties.

Izkārtojums A: Pi kā papildu vārteja esošajā LAN tīklā

Pieņemsim, ka ISP maršrutētājs ir 192.168.50.1, Pi ir 192.168.50.2 un atlasītie klienti norāda uz Pi. Svarīgi ir tas, ka divas dažādas pakešu plūsmas dala vienu kabeli. Klienta iekšējā pakete nonāk Pi un tai jāiziet caur tuneli; Pi pašas šifrētā pakete uz VPN partneri jāizlaiž pa to pašu kabeli uz maršrutētāju. Tās pārvietojas pretējos virzienos pa vienu un to pašu saskarni un prasa atšķirīgu apstrādi.

Dodiet Pi tā adresi caur instalēto tīkla pārvaldnieku, nevis caur vecu saskarnes faila recepti, kas ar to cīnās par ierīci. Pēc tam iestatiet klientus: statisku vārteju vienā ierīcē vai DHCP rezervāciju, kas izsniedz 192.168.50.2 kā maršrutētāju. Nemainiet visu maršrutētāja DHCP diapazonu divu ierīču dēļ un nepieņemiet, ka klients respektē šo opciju — pārbaudiet to.

Vājums ir strukturāls, nevis labojams. Jebkurš klients šajā segmentā var norādīt uz 192.168.50.1 un iziet atklāti, un ierīce ar otru saskarni vai mobilo radio pilnībā pamet jūsu izpildes ceļu. Ja šis teikums attiecīgajai ierīcei nav pieņemams, atbilde jau ir: izmantojiet izkārtojumu B.

Izkārtojums B: atsevišķs ports ieslēdz ierīces iekšā

Šeit Pi saglabā 192.168.50.2 augšupceļā ar vārteju 192.168.50.1 un otrajā saskarnē paņem 10.20.0.1/24 pievienotajām ierīcēm. Tagad Pi ir maršrutētājs ar diviem tīkliem, un pievienotajam segmentam ir tieši viena izeja.

Pirms apņemties pārbaudiet diapazonu pret visu pārējo: paša tuneļa apakštīklu, citus starpvietņu prefiksus un visu, kas sasniedzams caur VPN. 10.20.0.0/24, kas saduras ar attālu LAN, dod to pusstrādājošo rezultātu, kura diagnostika prasa veselu vakaru. Ja otrais ports ir USB adapteris, apstipriniet, ka tas tiek atbalstīts, un nofiksējiet tā nosaukumu tīkla pārvaldniekā, lai pārkārtošana pēc pārstartēšanas nepārvietotu jūsu LAN adresi.

Darbiniet DHCP klausītāju tikai šajā saskarnē. Serveris, kas atbild augšupceļā, konkurē ar ISP maršrutētāju un izdala jūsu segmenta adreses pārējai mājai. Piesaistiet to LAN saskarnei, ierobežojiet ar deklarēto diapazonu un turiet Pi pašas adresi ārpus baseina.

Pāradresācija, tulkošana un aizvēršanās noteikums kļūmes gadījumā

Četras lietas bieži tiek aprakstītas kā viena un nav. Pāradresācijas ieslēgšana (net.ipv4.ip_forward=1) tikai pasaka kodolam, ka tas drīkst pārvietot paketes starp saskarnēm; tas pats par sevi neko neļauj un negarantē nekādu ceļu. Izejas izvēle ir maršrutēšanas lēmums. Paketes atļaušana ir politikas lēmums forward ķēdē. Tās avota pārrakstīšana ir postrouting lēmums. Uzbūve, kas dara tikai pirmo, dod Pi, kas priecīgi pāradresē klientu trafiku ārā pa augšupceļu.

Ierobežojiet atļauju ar tiem avotiem, kurus domājāt, un ar to saskarni, kas trafikam jāizmanto, un iekļaujiet atgriešanās ceļu un Pi pašas vajadzīgos galamērķus. Pēc tam tulkojiet tuneļa izejā, ja pakalpojumu sniedzējs jūsu LAN prefiksu neatgriež atpakaļ pie jums. nftables rokasgrāmata pāradresāciju, lokālo izvadi un avota tulkošanu aplūko kā atsevišķas darbības, un tas šeit ir pareizais domāšanas modelis.

Biežā kļūda ir plašs masquerade noteikums fiziskajā saskarnē. Tad trafiks sasniedz internetu pa ISP ceļu, kamēr no klienta puses tas izskatās tieši kā strādājošs VPN. Tas neko nepierāda. Turiet tulkošanu piesaistītu deklarētajai izejai un turiet savus noteikumus ugunsmūrī, ko saimnieks jau izmanto, tā vietā lai pievienotu konkurējošu noteikumu kopu, kas iztukšo koplietotu postrouting ķēdi.

Pēc tam risiniet tuneļa neesamību. Klienta profils, kas instalē plašu noklusējuma maršrutu, nozīmē arī to, ka, tunelim krītot, parastais noklusējums var atgriezties un klienta trafiks klusi atgriežas augšupceļā. Tur, kur atgriešanās pie atklāta teksta nav pieņemama, forward politikai ir skaidri jānoraida trafiks no klienta uz augšupceļu, stāvoklī, kad VPN maršruts ir pazudis. Rakstiet to kā noraidījuma noteikumu, nevis pieņēmumu. Pi pašas šifrētais transports uz VPN partneri ir atsevišķa local-output plūsma un tai jāpaliek atļautai, citādi tunelis nekad nevarēs atgriezties.

DNS un IPv6 vajag savu atbildi

Ja klienti izmanto Pi kā risinātāju, viņi nonāk pie vietējā klausītāja un Pi sāk jaunu vaicājumu. Šis augšupējais vaicājums seko Pi pašas maršrutam, nevis forward noteikumam, ko rakstījāt klientiem, tāpēc klienta ceļš tikai caur tuneli plus risinātājs, kas iziet tieši, ir noplūde bez nekāda kļūdas ziņojuma. Izlemiet apzināti: risinātājs, kas sasniedzams caur tuneli, vai vietējais, ko pieņemat kā tiešu, un saskaņojiet Pi pašas izvades politiku ar šo lēmumu.

IPv6 atkal ir atsevišķs gadījums. IPv4 forward noteikums neko neierobežo attiecībā uz IPv6, un maršrutētāja paziņojumi augšupceļā var dot Pi un caur to pievienotajam segmentam otru noklusējumu, kas apiet jūsu politiku. Vai nu dodiet IPv6 savu aizsargāto ceļu pēc tā paša principa, vai skaidri ierobežojiet to klientu segmentā un sakiet to.

Pārbaudiet robežu, pirms tai uzticaties

Pieņemiet projektu tikai pēc četrām atsevišķām pārbaudēm, jo vilinošais vienīgais tests — atvērt pārlūku vienā klientā — iztur vairākos salūzušos stāvokļos.

Apstipriniet, ka viens īsts klients sasniedz internetu caur tuneli, pēc tam apstipriniet, ka tas pats klients nevar sasniegt internetu, kad tunelis ir nostādināts. Apstipriniet, ka DNS izšķiršana darbojas un vaicājums iziet tur, kur bijāt iecerējis. Apstipriniet, ka Pi pašas transports joprojām darbojas pēc tuneļa pārstartēšanas un ka atjaunošana neprasa mašīnas pārstartēšanu. Visbeidzot pārbaudiet ierīci, kuru neizvēlējāties: izkārtojumā A tai jāturpina darboties normāli, bet izkārtojumā B tai šajā segmentā nevajadzētu būt vispār.

• Divi porti un noraidījuma noteikums dod izpildi; viens ports un DHCP opcija dod padomu.
• Tulkošana nepareizajā saskarnē izskatās pēc panākuma un nav tā.
• Pi pašas trafiks, DNS un IPv6 katrs prasa lēmumu, nevis secinājumu.