Programėlė teigia, kad tunelis sveikas, o vis dėlto pusė reikalingų paskirčių niekada neatsako. Refleksas yra pridėti trasą arba sumažinti metriką, ir būtent šis refleksas yra mitas, kurį verta nužudyti pirmiausia. Kai kliento LAN ir tunelio baseinas pretenduoja į tą patį prefiksą, maršrutų lentelė laiko du nesuderinamus faktus, ir nei numatytoji trasa, nei metrika jų neišsprendžia. Taisymas yra adresavimo sprendimas, ir joks maršrutų redagavimas jo nepakeičia.

Kodėl papildoma trasa negali padalinti vieno prefikso

Trasa negali atskirti dviejų pretenzijų į vieną prefiksą, todėl protingas žingsnis yra nustoti ieškoti tinkamos maršruto eilutės. Stekas nepastatys identiško prefikso prieš prijungtą trasą, o tikslesnis įrašas pagama adresą, bet padaro jį turintį vietinį mazgą nepasiekiamą. Tai, kas atrodo kaip maršrutizavimo problema, yra adresavimo susidūrimas, ir abu taisymai keičia adresus, o ne maršrutus. Išbandykite šį teiginį savo kompiuteryje prieš jį priimdami.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Paklauskite sistemos apie vieną adresą ir atkreipkite dėmesį, kurią sąsają ji įvardija. Linux, macOS ir Windows atsako tik skaitymo paieška, kuri nurodo pasirinktą sąsają ir kitą šuolį nieko nesiųsdama. Kai atsakymas rodo fizinį adapterį, kai tunelis veikia, branduolys adresą laiko esantį nuorodoje, o ne kuo nors, ką tunelis galėtų nešti.

Padėkite tiekėjo suteiktą prefiksą šalia to, kurį aptarnauja namų maršrutizatorius, ir palyginkite juos kaip eilutes. Tikslus sutapimas yra aiškus atvejis, o platesnis tiekėjo baseinas, kuriame yra namų potinklis, žlunga taip pat, tik jį lengviau praleisti. Du prefiksai, kurie tik atrodo panašūs, nėra susidūrimas, todėl užrašykite abu prieš ką nors keisdami.

Perskaitykite baseiną, kurį klientas iš tikrųjų gavo

Skaitykite, ką gavo klientas, o ne tiekėjo rinkodaros puslapį. Padidinkite OpenVPN kliento žurnalo išsamumą ir serverio stumiamos trasos jame pasirodys, atskleisdamos tunelio prefiksus; kitur baseinas matomas ryšio informacijoje arba pačiame adapteryje. Paprašykite tiekėjo viso naudojamų privačių diapazonų sąrašo, nes vienas /24 šiandien gali būti du rytoj. Vengti įprastų RFC 1918 blokų nėra tas pats, kas vengti jums iš tikrųjų skirto paskirstymo.

Baseinas gali ir susitraukti, arba persikelti tarp regionų, todėl sąrašui reikia datos ir atsakingo asmens. Bet kurį tiekėjo atsakymą, senesnį už jūsų paskutinį plano pakeitimą, laikykite spėjimu, o ne faktu. Paklauskite dar kartą prieš įsipareigodami diapazonui, ir laikykite atsakymą su tinklo pastabomis, kad kitas žmogus paveldėtų įrodymą.

Pernumeravimas yra taisymas, kurį galite atlikti

Jei VPN serveris ne jūsų, kad jį pakeistumėte, namų LAN perkėlimas yra vienintelis galimas taisymas, ir tai įprasta situacija su komerciniu tiekėju. Pasirinkite diapazoną už tiekėjo baseino ir už diapazonų, kurių gali prireikti vėliau, ir patikrinkite jį pagal kiekvieną kitą vietą, kurią pasiekiate tuneliu. Tikitės trumpo sutrikimo ir ilgesnio užmirštų įrenginių uodegos: įrenginys, vis dar turintis seną adresą, atrodo veikiantis, kol jam prireikia šliuzo.

  1. Pirmiausia inventorius: paties maršrutizatoriaus adresas, DHCP sritis, rezervacijos, prievadų peradresavimai ir kiekvienas įrenginys, kurio adresas įvestas ranka.
  2. Tada pakeiskite maršrutizatoriaus LAN prefiksą ir DHCP sritį kartu priežiūros lange, ir atnaujinkite laidines nuomas prieš belaides.
  3. Po to ištaisykite statinius adresus: spausdintuvai, tinklo saugykla, viskas su kietai įrašytu šliuzu.
  4. Galiausiai iš naujo prijunkite VPN klientą ir patvirtinkite, kad tunelio adresas nebeatsiduria su LAN.

Pereikite adresus ta tvarka, o ne visus iš karto, ir kurį laiką palikite seną diapazoną dokumentuotą, kad pasenęs įrenginys būtų atpažįstamas, o ne paslaptingas. Įrenginys, kuris niekada neatnaujina, praneša apie save nepasiekdamas šliuzo, ir tai yra daug geresnė užuomina nei skambutis į pagalbą. Jei maršrutizatorius dalija ilgesnes nei paros nuomas, sutrumpinkite jas lango trukmei.

Ką gali ir ko negali padaryti slapyvardis

Kai serveris jūsų, adresų vertimas kliente gali atskleisti nuotolinį prefiksą laisvame vietiniame diapazone, todėl tas pats mazgas atsako antru adresu. Bendruomeninė OpenVPN tai daro su client-nat, ir ši direktyva būdinga būtent tam klientui, jos nėra komerciniuose ir mobiliuosiuose klientuose, su kuriais ji paprastai lyginama. Sąranka reikalauja trasos, atitinkančios vertimą, laisvo diapazono slapyvardžiui ir serverio, pasirengusio atsakyti į neišverstą kliento adresą. Niekas iš to nepadeda, kai klientas priklauso valdomam tiekėjui, kurio negalite konfigūruoti.

Kai pakeitimas įsigalios, pasiekite vietinį ir nuotolinį mazgą pirmiausia pagal adresą, paskui pagal vardą, ir pažymėkite trasą, kurią sistema pasirenka kiekvieną kartą. Vardas vis dar gali išsispręsti į seną diapazoną, todėl adresai ir vardai nusipelno atskirų patikrinimų. Paleiskite iš naujo vieną klientą ir vieną serverio pusės įrenginį, jei kuris nors iš jų veikė viso pakeitimo metu, nes podėlyje saugomi kaimynų įrašai gyvena ilgiau nei pakeitimas.

Užrašykite prefiksus, prie kurių sustojote, ten, kur žmonės iš tikrųjų žiūri: tinklo pastabose, pačiame maršrutizatoriaus komentaro lauke, supažindinimo puslapyje. Kažkas vėl pasirinks 192.168.1.0/24, ir susidūrimas grįš kartu su juo.

Susiję straipsniai