Dante SOCKS caur VPN: pilns tunelis pret maršrutēšanu pēc avota

Jūs vēlaties, lai SOCKS starpniekservera trafiks izietu caur VPN, bet pārējā resursdatora daļa saglabātu ierasto ceļu. To dara divi risinājumi, un tie atšķiras ar to, kas salūzt, kad kaut kas noiet greizi. Viens iespiež noklusējuma maršrutu tunelī un pēc tam to apiet; otrs atstāj galveno tabulu neskartu un sūta vienu avota adresi uz otru tabulu. Otrais ir tīrāks, un tam ir savi slazdi.

Divi risinājumi, divi atšķirīgi bojājumu rādiusi

Pilna tuneļa risinājums ir tas, ko lielākā daļa VPN klientu dara pēc noklusējuma: aizstāj noklusējuma maršrutu, lai viss iet pa tuneli, un pēc tam izslēdz to, kam tur nav jābūt. To ir viegli saprast un grūti noturēt šauru, jo katrs pievienotais lokālais serviss pārmanto tuneli, līdz jūs to izslēdzat. Bojājumu režīms ir plašs, jo viens nepareizs maršruts aizrauj līdzi arī paša resursdatora savienojumu.

Avota izvēles risinājums iet pretējā virzienā. Galvenā tabula paliek tāda, kāda bija, un viens politikas noteikums sūta paketes no konkrētas lokālas adreses uz tabulu ar tuneļa noklusējumu. Nekas cits nemainās, kas nozīmē, ka bojājumu rādiuss ir viena adrese.

Šis šaurums ir arī ierobežojums: risinājums darbojas tikai tad, ja starpniekservera izejošās paketes patiešām nes šo adresi.

Ko dara Dante external iestatījums

Iestatījums external izvēlas adreses, ko starpniekserveris izmanto izejošajiem savienojumiem; tas neaiztiek kodola maršrutēšanas politiku. Tieši šī atdalīšana padara iespējamu otro risinājumu, un tieši tur cilvēki nepareizi lasa dokumentāciju. Norādot external uz tuneļa adresi, starpniekserveris sāk savienojumus no šīs adreses, un tad maršrutu tabula izlemj, kur šīs paketes dodas.

Klausītājs ir atsevišķs jautājums. Ierobežojiet internal tikai tiem klientiem, kuriem jāizmanto starpniekserveris, pieprasiet autentifikāciju un aizveriet portu ar firewall, jo atvērts klausītājs nav VPN izejas funkcija.

Pārliecinieties, ka konfigurētā adrese patiešām pieder tunelim starpniekservera tīkla vārdu telpā.

Avota izvēles tabulas veidošana

TUN adresei 10.90.0.2/24 ar sasniedzamu peer adresi 10.90.0.1 un tabulas numuru, ko nekas cits neizmanto, izkārtojums izskatās šādi:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

unreachable maršruts ir tā daļa, ko cilvēki izlaiž. Bez tā tabula, kuras tuneļa maršruts pazūd, nokrīt uz parasto noklusējumu, un starpniekserveris klusi iziet caur WAN. Ar to meklēšana neizdodas, kas ir redzams bojājums klusa noplūdes vietā. Arī noteikuma prioritātei jābūt priekšā visam, kas atbilst šim avotam.

Šīs vērtības apraksta vienu topoloģiju. Point-to-point peer, net30 adresācija un klienti, kas izsniedz citu prefiksu, visiem vajag savus maršrutus, tāpēc kopējiet formu, nevis adreses.

Kur noplūst avota noteikums

Noteikums, kas atbilst avota adresei, ietekmē katru procesu, kas to izmanto, ne tikai starpniekserveri. Ja cits dēmons piesaista to pašu adresi, arī tā trafiks iet pa tuneli, un bojājums izskatīsies kā nesaistīta servisa problēma. Dodiet starpniekserverim adresi, ko nekas cits neizmanto, vai pieņemiet, ka tvērums ir adrese, nevis process.

DNS ir otra noplūde. Resolver ligzda ne vienmēr izmanto starpniekservera external datu savienojuma avotu, tāpēc nosaukumu meklēšana joprojām var iziet caur WAN. Pārbaudiet atrisināšanu atsevišķi no savienojuma izveides un izlemiet, vai šāds iznākums ir pieņemams.

IPv6 vajag savus noteikumus un maršrutus, jo IPv4 izkārtojums par to neko nepierāda.

Izvēlieties pēc bojājuma, ko spējat pieļaut

Izvēlieties pilnu tuneli, kad resursdators jāaizsargā kopumā un jūs varat uzturēt izņēmumu sarakstu. Izvēlieties maršrutēšanu pēc avota, kad resursdatoram jāsaglabā savs ceļš un jānovirza tikai viens serviss. Abi ir likumīgi; kļūda ir izvēlēties vienu un pēc tam testēt to tā, it kā tas būtu otrs.

Lai ko jūs izvēlētos, pārbaudiet no abām pusēm: pieprasījumu caur starpniekserveri un tiešu pieprasījumu no resursdatora, katram pierakstot novēroto izejas adresi.

Ja tunelis nokrīt, iepriekš izlemiet, vai starpniekserverim jāatkrīt vai jāpārslēdzas uz rezervi, un ļaujiet maršrutu tabulai izteikt šo lēmumu.