Norite, kad SOCKS tarpinio serverio srautas išeitų per VPN, o likusi hosto dalis išlaikytų įprastą kelią. Tai daro du sprendimai, ir jie skiriasi tuo, kas sugenda, kai kažkas nepavyksta. Vienas įstumia numatytąjį maršrutą į tunelį ir paskui jį apeina; kitas palieka pagrindinę lentelę ramybėje ir siunčia vieną šaltinio adresą į antrą lentelę. Antrasis yra švaresnis, ir jis turi savų spąstų.

Du sprendimai, du skirtingi žalos spinduliai

Viso tunelio sprendimas yra tai, ką dauguma VPN klientų daro pagal nutylėjimą: pakeisti numatytąjį maršrutą, kad viskas eitų tuneliu, o paskui išskirti tai, kas neturėtų. Jį lengva suprasti ir sunku išlaikyti siaurą, nes kiekviena pridedama vietinė paslauga paveldi tunelį, kol jos neišskiriate. Gedimo režimas yra platus, nes vienas neteisingas maršrutas pasiima ir paties hosto ryšį.

Šaltinio pasirinkimo sprendimas eina priešinga kryptimi. Pagrindinė lentelė lieka tokia, kokia buvo, o viena politikos taisyklė siunčia paketus iš konkretaus vietinio adreso į lentelę su tunelio numatytuoju maršrutu. Niekas kitas nesikeičia, o tai reiškia, kad žalos spindulys yra vienas adresas.

Šis siaurumas kartu yra ir apribojimas: sprendimas veikia tik tada, jei tarpinio serverio išeinantys paketai tikrai neša tą adresą.

Ką daro Dante external nustatymas

Nustatymas external parenka adresus, kuriuos tarpinis serveris naudoja išeinančioms jungtims; jis neliečia branduolio maršrutizavimo politikos. Būtent šis atskyrimas leidžia antrąjį sprendimą, ir būtent čia žmonės neteisingai skaito dokumentaciją. Nukreipus external į tunelio adresą, tarpinis serveris pradeda jungtis iš to adreso, o tada maršrutų lentelė nusprendžia, kur tie paketai keliauja.

Klausytojas yra atskiras klausimas. Apribokite internal tik tiems klientams, kurie turi naudoti tarpinį serverį, reikalaukite autentifikavimo ir uždarykite prievadą už ugniasienės, nes atviras klausytojas nėra VPN išėjimo funkcija.

Patvirtinkite, kad sukonfigūruotas adresas tikrai priklauso tuneliui tarpinio serverio tinklo vardų erdvėje.

Šaltinio pasirinkimo lentelės kūrimas

TUN adresui 10.90.0.2/24 su pasiekiamu peer adresu 10.90.0.1 ir lentelės numeriu, kurio niekas kitas nenaudoja, išdėstymas atrodo taip:

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šrutas yra ta dalis, kurią žmonės praleidžia. Be jo lentelė, kurios tunelio maršrutas dingsta, nukrenta į įprastą numatytąjį maršrutą, ir tarpinis serveris tyliai išeina per WAN. Su juo paieška nepavyksta, o tai yra matomas gedimas vietoje tylaus nuotėkio. Taisyklės prioritetas taip pat turi būti prieš viską, kas atitinka tą šaltinį.

Šios reikšmės apibūdina vieną topologiją. Point-to-point peer, net30 adresavimas ir klientai, kurie išduoda kitą prefiksą, visiems reikia savo maršrutų, todėl kopijuokite formą, o ne adresus.

Kur prateka šaltinio taisyklė

Taisyklė, atitinkanti šaltinio adresą, veikia kiekvieną procesą, kuris jį naudoja, o ne tik tarpinį serverį. Jei kitas daemon prisiriša prie to paties adreso, jo srautas taip pat eina tuneliu, ir gedimas atrodys kaip nesusijusi paslaugos problema. Duokite tarpiniam serveriui adresą, kurio niekas kitas nenaudoja, arba pripažinkite, kad apimtis yra adresas, o ne procesas.

DNS yra kitas nuotėkis. Resolver lizdas nebūtinai naudoja tarpinio serverio external duomenų jungties šaltinį, todėl vardų paieškos vis tiek gali išeiti per WAN. Tikrinkite rezoliuciją atskirai nuo ryšio užmezgimo ir nuspręskite, ar toks rezultatas priimtinas.

IPv6 reikia savo taisyklių ir maršrutų, nes IPv4 išdėstymas nieko apie tai neįrodo.

Rinkitės pagal gedimą, kurį galite toleruoti

Rinkitės visą tunelį, kai hostas turi būti apsaugotas kaip visuma ir galite išlaikyti išimčių sąrašą. Rinkitės maršrutizavimą pagal šaltinį, kai hostas turi išsaugoti savo kelią ir turi būti nukreipta tik viena paslauga. Abu yra teisėti; klaida yra pasirinkti vieną ir paskui testuoti taip, lyg tai būtų kitas.

Kad ir ką pasirinktumėte, tikrinkite iš abiejų pusių: užklausą per tarpinį serverį ir tiesioginę užklausą iš hosto, kiekvienai užrašydami stebėtą išėjimo adresą.

Jei tunelis nukrenta, iš anksto nuspręskite, ar tarpinis serveris turi žlugti, ar pereiti prie atsarginio kelio, ir leiskite maršrutų lentelei išreikšti tą sprendimą.

Susiję straipsniai