Ką bypass-dhcp iš tikrųjų prideda prie OpenVPN maršrutų plano

Profilis su redirect-gateway def1 bypass-dhcp sujungia IPv4 numatytojo maršruto perrašymą su viena siaura išimtimi. Žmonės perskaito paskutinį žodį ir tikisi bendro mobiliojo ryšio sprendimo, o paskui praleidžia popietę su DHCP teorija, kurios ši vėliavėlė niekada nepalaikė. Kiekviena dalis daro vieną dalyką, o išimtis yra daug mažesnė už savo reputaciją.

Išskaidykite vėliavėles, prieš priskirdami tik mobiliajame tinkle pasitaikantį gedimą adresų priskyrimui. Abi tos eilutės pusės neturi nieko bendra viena su kita.

Dvi vėliavėlės, du nesusiję darbai

Su def1 klientas prideda du IPv4 pusinius numatytuosius maršrutus, o ne pakeičia jau esantį numatytąjį maršrutą. 0.0.0.0/1 apima apatinę adresų erdvės pusę, o 128.0.0.0/1 viršutinę, todėl kartu jie pasiekia bet kurią paskirties vietą, o kiekvienas lieka konkretesnis už 0.0.0.0/0. Todėl pradinis numatytasis maršrutas lieka lentelėje nelaimėdamas tų paieškų, o tai išlaiko senąją šliuzą pasiekiamą viskam, ką klientas nukreipia aiškiai. Tai taip pat palieka lentelėje du persidengiančius numatytuosius maršrutus, todėl maršrutų išrašas gali atrodyti keisčiau, nei siūlo profilis.

bypass-dhcp yra atskira ir visiškai neliečia numatytojo maršruto. OpenVPN 2.6 vadove jis aprašomas kaip tiesioginio maršruto į DHCP serverį, kuris nėra vietiniame potinklyje, pridėjimas, kad nuomos srautas išeitų už tunelio, ir pažymima, kad šis elgesys įgyvendintas Windows klientuose ir gali būti nepasiekiamas kitur.

Jo egzistavimo priežastis mechaninė. Kai pusiniai numatytieji maršrutai užvaldo išeinantį srautą, DHCP atnaujinimas, nukreiptas į serverį fiziniame tinkle, būtų nukreiptas į tunelį, jei kažkas to adreso nepriskirtų tikrajai sąsajai. Vėliavėlė jį priskiria.

Ką išimtis iš tikrųjų apima

Iliustracinė lentelė po sėkmingo prisijungimo parodo formą: du pusiniai numatytieji maršrutai per tunelį ir vienas prieglobos maršrutas DHCP serveriui per fizinę šliuzą. Skaitykite ją kaip formą, o ne kaip savo adresus.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

Ta trečioji eilutė įvardija vieną paskirties vietą. Tai nėra sprendėjo nustatymas, ne bendras leidimas vietiniam tinklui ir ne išėjimo taisyklė serveryje. Telefonas mobiliajame tinkle gali neturėti DHCP serverio, kurį klientas taip atpažintų, todėl vėliavėlė ten nieko nekeičia.

Patikrinkite, ką klientas iš tikrųjų įdiegė

Atskirkite profilyje įrašytą parinktį, serverio pasiūlytą parinktį ir maršrutą, kurį ryšio savininkas faktiškai pritaikė. Klientas, atmetantis nepalaikomą vėliavėlę, gali išsaugoti likusią konfigūraciją, todėl tunelis pakyla, o išimties tiesiog nėra. Skaitykite paties kliento žurnalą ir gautą maršrutų lentelę, o ne manykite, kad failo eilutė įsigaliojo. Trys iš šių gali būti teisingi vienu metu, ir tik paskutinis keičia, kur paketai iš tikrųjų keliauja.

Tuo pačiu metu palikite naudingą maršrutą į VPN galinį tašką. Ta galinio taško išimtis yra kitas reikalavimas nei DHCP išimtis, o be jos tunelis gali užvaldyti transportą, kuris jį palaiko.

Programos paskirties vietai ištirkite veiksmingą paiešką tame kontekste, kuriame ji nepavyksta. Konkretesni vietiniai maršrutai, politikos maršrutizavimas ir išimtys pagal programas keičia atsakymą, todėl dviejų pusinių numatytųjų maršrutų buvimas nėra kiekvieno srauto sąrašas.

Likusi kelio dalis nėra šioje vėliavėlėje

Serveriui vis dar reikia leidimo persiųsti kliento interneto srautą ir išėjimo tvarkos, kuri gali jį grąžinti. Joks kliento pusės maršrutas nesukuria trūkstamo persiuntimo ar šaltinio vertimo serveryje, ir jokia vėliavėlė nepakeičia veikiančio grįžimo kelio.

Vardų skyrimui ir IPv6 kiekvienam reikia savo politikos. IPv4 perrašymas nei nukreipia sprendėją į serverį tunelio pusėje, nei sukuria IPv6 aprėptį, o klientas, kuris peradresuoja tik v4, palieka v6 kelią nepaliestą.

Palyginkite vieną patvirtintą nekenksmingą užklausą veikiančiame ir nepavykstančiame prieigos kelyje, laikydami profilį ir paskirties vietą fiksuotus. Užrašykite, ar skirtumas yra vardų skyriime, tunelio sukūrime, maršruto pasirinkime ar persiųstame sraute, ir saugokite atsakymą kartu su profiliu. Būtent šis įrašas neleidžia kitam žmogui kaltinti DHCP problemoje, kurios jis negali pasiekti.