Masquerade vai politikas maršrutēšana: LAN trafiks caur VPN vārteju

Visu LAN novietot aiz VPN tuneļa ir vieglā daļa; izlemt, kā tālā puse redz šos klientus, nav. Masquerade pārraksta katru LAN avotu uz vārtejas tuneļa adresi, tāpēc tālā puse atbild vienam partnerim. Politikas maršrutēšana saglabā sākotnējās adreses un prasa, lai tālā puse zinātu, kā tās sasniegt. Neviens nav noklusējums; izvēle izriet no tā, kam pieder tālā puse un vai ir svarīga identitāte katrā ierīcē.

Abi risinājumi sola dažādas lietas

Masquerade samazina LAN līdz vienam redzamam saimniekam: vārtejai. Tālais tīkls atbild uz šo vienu adresi, un vārteja pārtulko atbildes atpakaļ klientam, kas uzsāka plūsmu. Tālajā pusē nav vajadzīgs maršruts uz jūsu privātajiem prefiksiem, tāpēc šis risinājums iztur piegādātāju, kas atsakās tos pārnēsāt. Vārteja kļūst arī par katra savienojuma avotu, tāpēc tālā puse nevar atšķirt divus klientus.

Politikas maršrutēšana saglabā katra klienta adresi neskartu. Tālais tīkls redz faktisko avotu un var to reģistrēt, piemērot noteikumu katram saimniekam vai sūtīt atbildi tieši uz šo adresi. Šī redzamība ir visa būtība, un tā nāk ar pienākumu: tālajai pusei jābūt maršrutam uz LAN prefiksu, kas ved atpakaļ caur tuneli. Izplānojiet šo maršrutu pirms noteikuma ieslēgšanas, jo tunelis tāpat pacelsies un trūks tikai atbilžu.

Kļūdu režīmi atšķiras tikpat daudz kā solījumi. Trūkstošs masquerade noteikums rada paketes, kas iziet ar privātiem avotiem un nekad neatgriežas. Trūkstošs atgriešanās maršruts rada to pašu simptomu politikas maršrutēšanā, bet labojums pieder tālajam maršrutētājam, nevis vārtejai.

Masquerade: viens partneris tālajā pusē

Masquerade ceļam ir secība, kas ir svarīga. Pārsūtīšanai jābūt ieslēgtai, pirms jebkurš NAT noteikums dod labumu, filtru tabulai jāļauj tranzīts abos virzienos, un tikai tad tulkojums tiek piemērots tuneļa saskarnē.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Klientiem joprojām vajadzīgs ceļš uz vārteju. Vai nu vārteja ir viņu noklusējuma maršrutētājs, vai viņi nes sev līdzi konkrētu maršrutu uz tālo prefiksu; ja atsevišķs maršrutētājs paliek noklusējums, tam vajadzīgs statisks maršruts uz tuneļa galamērķiem, citādi pakete nonāk nepareizā lēcienā, pirms vārteja to ierauga.

DNS ir atsevišķs lēmums. Tālās puses atrisinātājs atbild tikai tad, ja tā atbilde var atgriezties pie klienta. Masquerade gadījumā vaicājums izskatās, ka nāk no vārtejas, tāpēc atrisinātāja atgriešanās ceļš jau ir nodrošināts; politikas maršrutēšanas gadījumā atrisinātājam vajadzīgs tāds pats atgriešanās maršruts kā jebkuram citam tālam pakalpojumam.

Politikas maršrutēšana: saglabājiet avotu, pievienojiet atgriešanās ceļu

Politikas maršrutēšana sākas ar tabulu un noteikumu, kas to izvēlas. Trafiks, kas ienāk no LAN saskarnes, tiek sūtīts uz īpašu tabulu, un šī tabula satur noklusējuma maršrutu caur tuneli. Galvenā tabula paliek neskarta, tāpēc pašas vārtejas radītais trafiks var iet citu ceļu.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

Tad tālajai pusei jāmaršrutē LAN prefikss atpakaļ caur tuneli. Tā ir konfigurācija tālajā maršrutētājā, nevis šajā vārtejā. Vārtejai arī jāpieņem atbildes, kas pienāk citā saskarnē, nekā paredzētu galvenā tabula; vaļīga apgrieztā ceļa filtrēšana (rp_filter iestatīts uz 2) ir parastā korekcija, kad stingrais režīms izmet šīs paketes.

Kad divi tuneļi ir aktīvi, atzīmējiet katru plūsmu ieejā un ļaujiet atzīmei izvēlēties tabulu. Noteikums, kas skatās tikai uz ievades saskarni, sūta abu tuneļu trafiku uz vienu un to pašu tabulu, tāpēc otrais tunelis nozog plūsmas pirmajam. Pārbaudiet šo atzīmi ar savienojumu, kas pārdzīvo atkārtotu savienošanu, jo tad parādās jauktā politika.

Izlemiet pēc īpašumtiesībām un pēc tā, ko reģistrē tālā puse

Ja tunelis beidzas pie pakalpojumu sniedzēja, izmantojiet masquerade. Šis operators nemaršrutēs jūsu privātos LAN diapazonus, un tam nav iemesla atšķirt atsevišķus klientus aiz jūsu vārtejas. Viens redzams partneris ir vienīgais modelis, ko atbalsta tā politika, tāpēc dodiet tam to un turiet tulkojumu savā malā. Piegādātājs redz vienu partneri, kas ir tieši tas, ko gaida tā politika, un jūsu klienti manto šo vienoto identitāti.

Ja abi gali ir jūsējie un tālie pakalpojumi darbojas pēc avota adresēm, politikas maršrutēšana ir pelnījusi savu papildu maršrutu. Tad ugunsmūra noteikumi, piekļuve katram lietotājam un audita žurnāli var atšķirt klientus. Ja tālajai pusei vajadzīga tikai sasniedzamība, masquerade ir vienkāršāks un novērš veselu atgriešanās maršruta kļūdu klasi.

Hibrīdi risinājumi ir normāli: politikas maršrutēšana jūsu tīklā, masquerade piegādātāja malā. Svarīgi ir pierakstīt, kurš lēciens pārtulko un kurš lēciens maršrutē, jo nejauši pievienots NAT noteikums vienam klientam paslēpj avotu katram klientam tajā pašā ķēdē.

Pārbaudiet no viena klienta, tad no otra klienta

Veiciet testu tur, kur sākas trafiks. Pārbaudiet maršrutu, ko izmanto saimnieks, vērojiet, kā pakete parādās tuneļa saskarnē, un pārbaudiet conntrack tulkojuma dēļ. Šī secība pierāda, ka pakete gāja paredzēto ceļu, nevis vienkārši kaut kur nonāca.

Atkārtojiet testu pēc atkārtotas savienošanas. Masquerade noteikums, kas nosauc saskarni, pārdzīvo jaunu tuneļa adresi; noteikums, kas nosauc veco adresi, nepārdzīvo. Tad pārbaudiet otru LAN saimnieku, jo risinājums, kas darbojas vienā mašīnā, bieži ir atkarīgs no šīs mašīnas pašas maršruta, nevis no vārtejas politikas.

Pierakstiet izvēlēto modeli, pārtulkoto vai saglabāto avotu un atgriešanās maršruta īpašnieku vārtejas piezīmēs. Citādi nākamais cilvēks, kas pievienos klientu vai tuneli, minēs, un minēšana ir tas, kā strādājošs LAN-uz-VPN iestatījums kļūst daļējs.