Kaks teenuseaadressi ühel OpenVPN-kliendil: iroute ja lo

Rakendus vastab oma tunneliaadressil, ja aadress, mille te selle jaoks dokumenteerisite, ei vii kuhugi. OpenVPN logis ei kaeble miski, partner näib ühendatud ja jaotur loetleb täpselt ühe kliendi. Lünk on selles, et teine aadress kliendil on kaks eraldi fakti: host peab selle omanikuks olema ja jaotur peab teadma, milline partner seda omab. Käsitlege üht ilma teiseta ja liiklus kas sureb jaoturis või saabub ilma kojuviiva marsruudita.

Alias on kohalik, omand on kaugel

Tunneliaadress läbiräägitakse, nii et mõlemad pooled õpivad selle kätlemise ajal. Täiendavat teenuseaadressi ei läbiräägita üldse, mistõttu selle lisamine iseenesest ei muuda jaoturis midagi. Klient võib aadressi kohe omada ja server saadab selle liikluse ikkagi oma vaikimisi teele või viskab selle ära. Luua tuleb kaks kirjet, kahes erinevas kohas.

Kliendil kuulub aadress hostile ja loopback on loomulik kodu teenuseidentiteedile, mis ei tohiks kunagi füüsilisel lingil esineda. Jaoturis on partneri ja eesliite vastendamine eraldi deklaratsioon, mida loeb ainult server. Kumbki kirje ei eelda teist.

Hoidke kaks vahemikku eraldi ka oma märkmetes. Näites olevad aadressid on dokumentatsiooniväärtused ja nende kattumine päris LAN-iga on kõige kiirem viis muuta töötav seadistus katkiseks näivaks.

Lisage aadress kliendile püsivalt

Asetage teenuseaadress loopbackile hosti eesliitega, et host käsitleks seda kohaliku sisendina, mitte saavutatava alamosana. ip address add 10.66.0.10/32 dev lo teeb seda ühe aadressi jaoks ja käsu kordamine teise aadressi jaoks modelleerib kahte teenust.

Käivitage see ühekordse testina ja seejärel viige see sinna, mis omab hosti võrgukonfiguratsiooni, sest käitusaegne lisand kaob taaskäivitamisel ja duplikaadid kogunevad ühenduste vahel. Pärast võrku järjestatud systemd-üksus on üks võimalus ja distributsiooni võrguhaldur on teine. Mida iganes te valite, aadress peab olemas olema enne, kui rakendus sellega liitub, muidu tõuseb teenus valele soklile. Kontrollige ip address show dev lo abil pärast taaskäivitamist, mitte pärast käsitsi käsku.

Sidumine on aadressimääramisest eraldi otsus. Rakendus, mis kuulab igal aadressil, võtab vastu liiklust liidestel, mida te kunagi ei kavatsenud, seega suunake see konkreetsele teenuseaadressile. Siis on kohalikul sisendipoliitikal, millega täpselt sobida.

Nõudke see CCD-failis, mida jaotur tegelikult loeb

Serveris läheb omandideklaratsioon kliendipõhisesse faili, mille valib autenditud ühisnimi, client-config-dir nimetatud kataloogi sees. Rida on iroute 10.66.0.10 255.255.255.255, üks aadressi kohta, ja see ütleb serverile, milline partner peaks selle sihtkoha liiklust vastu võtma.

Kaks detaili rikuvad selle vaikselt. Failinimi peab ühtima nimega, mida server tegelikult kasutab, mis erineb, kui mängus on username-as-common-name. Ja iroute mõjub ainult TUN-režiimis, kui kliendikonfiguratsiooni kataloog on seadistatud, seega sama rida ei tee sillatud juurutuses midagi. Lisage read olemasolevasse faili, mitte ärge asendage seda, sest see võib juba kanda fikseeritud aadressi või push-valikuid. OpenVPN 2.6 viide dokumenteerib nii kataloogi kui ka omandidirektiivi.

Ka jaoturi enda tuum vajab teed nende sihtkohtadeni, et kohapeal loodud liiklus jõuaks tunneliprotsessi. Serveri konfiguratsioonis route 10.66.0.10 255.255.255.255 katab liiklust, mille server ise loob, samas kui teised kliendid vajavad push "route 10.66.0.10 255.255.255.255", et sihtkoha ise õppida.

Marsruutimine ja autoriseerimine jäävad eraldi. Lükitud marsruut ütleb kliendile, kuhu pakette saata, ja ei anna midagi; teenus peab kutsuja ikkagi oma tingimustel vastu võtma.

Kontrollige sisendipoliitikat ja vastuseteed

Aliasele adresseeritud pakett saabub omavale hostile kohaliku sisendina, seega küsimus on, kas kohalik tulemüür lubab seda allikat ja porti. Lubage konkreetne teenuseport VPN-i allikavahemikust, mitte ärge avage kogu aadressi.

Vastused vajavad tagasiteed kutsujani. Tavalise tunnelibasseini sees oleva kutsuja jaoks on see tee juba olemas, sest tunneliseade kannab seda. Teise marsruuditud võrgu taga olev kutsuja vajab ka selle võrgu tagasiteed ja just siin kaotavad asümmeetrilised seadistused pakette.

Jälgige teist kuulajat samal pordil, mis on seotud teise aadressiga, sest tuum edastab sobivale soklile ja tulemused näivad juhuslikud. Kontrollige ss -lntp abil ja kinnitage, et seotud aadress on teenusealias. Lähtekohta NAT-i siin ei vajata ja selle lisamine varjab kutsuja identiteeti, millest teie logid sõltuvad.

Testige aadresse ja omandit eraldi

Testige kahes etapis. Kõigepealt kinnitage, et omav host pääseb teenusele oma aliasel enda juurest, mis eraldab sidumis- ja tulemüüriproblemid marsruutimisest. Seejärel testige tõelise VPN-i kutsuja poolt, kasutades rakenduse enda autentimist. Kui esimene läbib ja teine ei, on puuduv tükk jaoturi poolel.

Kontrollige ka rikkerežiime, mis elavad ühendusest üle: alias jääb määratuks ka siis, kui tunnel on maas, ja jaotur hoiab oma marsruuti, kui partner puudub. Ükski objekt üksi ei tõesta, et teenus on kättesaadav, ja seetõttu võidab kaheetapiline test ühe pingi sülearvutist.