Kāpēc vien route-nopull atstāj failu serveri nesasniedzamu
Stumto maršrutu ignorēšana ir tikai puse no sadalīta tuneļa. Izvēlieties maršruta īpašnieku, pievienojiet biroja prefiksu ar roku un pārbaudiet trīs plūsmas, pirms saukt to par izlabotu.
Failu serveris atveras labi, un blakus logā videozvans sāk raustīties. Nekas nav lēns un neviens MTU nav nepareizs: jūsu klients pieņēma servera doto maršrutu sarakstu, tāpēc tagad katrs pakets iziet caur biroja ugunsmūri. Risinājums nav vēl viens regulēšanas karodziņš, bet lēmums par to, kam pieder klienta maršrutu tabula. Šis lēmums pieder vienai vietai, un tālāk aprakstītie atteices veidi pasaka, kuru vietu jūs patiešām izvēlējāties.
Izlemiet, kam pieder maršrutu tabula
Iespējami trīs īpašnieki. Serveris var stumt maršrutus un noklusējuma vārteju, un tad klients instalē visu, kas tam tiek teikts, un kļūst par pilnu tuneli. Klienta profils var pārņemt īpašumtiesības, atmetot stumšanas un nesot savas maršrutu rindas. Darbvirsmas savienojumu pārvaldnieks arī var būt lēmuma īpašnieks, izmantojot savas maršruta un noklusējuma maršruta īpašības.
Katra izvēle neizdodas citādi, tāpēc ir vērts izlasīt tabulu pirms profila rediģēšanas. Rinda, kas atbilst jūsu simptomam, ir īpašnieks, kāds jums patiešām ir.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Izvēlieties vienu un pierakstiet to. Divu sajaukšana atstāj resursdatoru, kura noklusējuma ceļš ir pretrunā ar tā paša dokumentāciju, un nākamais inženieris nevar pateikt, kurš slānis uzvarēja. Dzēsiet zaudētāju skaidri.
route-nopull filtrē stumšanas, tas nepievieno maršrutus
route-nopull pieder klienta profilam, un tā secība šajā failā nav svarīga, jo tas tikai atmet vērtības, kas nāk no servera. Tas atmet stumtos maršrutus, tostarp stumto noklusējuma maršrutu, kamēr tunelis joprojām ceļas normāli.
Sekas, ko cilvēki palaiž garām, ir tādas, ka stumtie DHCP parametri iet kopā ar tiem. Arī servera sūtītie DNS iestatījumi tiek atmesti, tāpēc iekšējie nosaukumi pārstāj atrisināties, lai gan tunelis ir vesels un serveris ir sasniedzams pēc adreses.
Tas atstāj tuneli bez ceļa uz biroja prefiksu, ja vien jūs pats to nepievienojat: tajā pašā profilā route-nopull un pēc tam route 10.30.0.0 255.255.0.0. Šī rinda nes adresi un masku; tā nenosauc nākamo lēcienu.
Alternatīva forma pievieno vārtejas marķieri, route 10.30.0.0 255.255.0.0 vpn_gateway, kas ierakstu pēc nosaukuma vērš uz tuneli. Importētāji atšķiras ar to, vai tie tulko šo variantu, tāpēc pārbaudiet saglabāto savienojumu, ja ieraksts trūkst kodola tabulā.
Pārbaudiet ar maršrutu meklējumiem, nevis ar ping
Ping pasaka, ka kaut kas atbildēja. Maršruta meklējums pasaka, kuru saskarni kodols izvēlētos, un tas ir jautājums, ko jūs patiešām uzdevāt. Četras īsas komandas atdala trūkstošu maršrutu no maršruta, kas norāda uz nepareizo ierīci.
Izlasiet, ko tunelis instalēja, izmantojot ip route show dev tun0. Pilnīgi nekāda izvade nozīmē nulle maršrutu, kas nav strādājošs sadalīts tunelis, un tas ir parastais rezultāts, pievienojot filtru bez skaidras rindas.
Pēc tam pārbaudiet vienu biroja adresi ar ip route get 10.30.5.7 un vienu parastu interneta adresi ar ip route get 1.1.1.1. Otrajam jānosauc fiziskā saskarne; ja tā nosauc tuneli, stumšana vispār netika filtrēta.
Visbeidzot izlasiet ip rule, jo iepriekšējā mēģinājuma atstātais politikas noteikums var pārspēt tikko laboto tabulu. Pareizs profils ar novecojušu noteikumu virsū izskatās tieši kā salauzts profils. Dzēsiet noteikumu, ko pievienojāt pēdējā reizē, pirms pievienojat vēl vienu.
Pārklājošies apakštīkli izskatās kā salauzts tunelis
Divi privātie diapazoni var būt identiski no klienta viedokļa, un tieši tur sadalīts tunelis tiek vainots kaut kā tādā, ko tas nav izraisījis. Ja birojs izsniedz to pašu prefiksu, ko izmanto jūsu mājas maršrutētājs, tuneļa maršruts nosedz maršrutētāju, un mājas tīkls izskatās pazudis.
Salīdziniet adresi savā saskarnē ar maršrutu, ko instalē profils, izmantojot vienkāršu adrešu sarakstu, pirms kaut ko maināt. Pārklāšanās ir reāla, un neviena profila opcija to neatrisina. To, ko varat labot, ir nosaukumu piešķiršana, lai nākamais cilvēks redzētu divus diapazonus, nevis vienu.
Godīgie labojumi ir pārnumurēt vienu pusi vai tulkot adreses birojā. Viena resursdatora maršruta piespraušana pie maršrutētāja darbojas, līdz mainās maršrutētāja adrese, un tad tā kļūst par otru noslēpumu virs pirmā.
Lai lēmums pārdzīvo atkārtotu savienojumu
Ar roku ievadīti ieraksti nepārdzīvo atkārtotu savienojumu, un savienojumu pārvaldnieks tabulu pārbūvē katru reizi, kad profils sākas. Ielieciet lēmumu tur, kur savienojums tiek izveidots, vai tas būtu profils vai pārvaldnieka saglabātie iestatījumi. Pēc tam vienreiz apzināti restartējiet savienojumu, nevis atklājiet uzvedību zvana laikā. Profils, kas darbojas tikai līdz nākamajam atkārtotajam savienojumam, nav pabeigts.
Praktizējiet trīs ceļus vienlaikus: biroja resursdatoru pēc burtiskās adreses, to pašu resursdatoru pēc nosaukuma un parastu publisku vietni. Vidējais ir atkarīgs no nosaukumu pakalpojuma, ko konfigurējāt pēc stumto DNS opciju atmešanas, un tieši tas klusi neizdodas.