Jauns hotspot klients, kas iestrēdzis pie IP iegūšanas, nav VPN kļūda

Tālrunis pievienojas hotspotam, paliek pie «Notiek IP adreses iegūšana» un beigās padodas. Dabiskais secinājums ir, ka tālruņa VPN traucē DNS, tāpēc cilvēki sāk rediģēt risinātājus un pievienotos noteikumus. Tas ir nepareizais posms. Klients nekad nav saņēmis vietējo adresi, un bez tās tam nav vārtejas, nav risinātāja un nav ko tālāk nodot, tāpēc neviens VPN iestatījums uz resursdatora tālruņa nevar izskaidrot šo kļūdu. Savienošanās, vietējās adreses piešķiršana un tālāknodošana ir trīs atsevišķi posmi, un tikai pēdējais attiecas uz tuneli.

Trīs posmi un kurā jūs esat

Vispirms nāk savienošanās: klients pievienojas hotspota bezvadu tīklam. Nepareiza parole, WPA3 neatbilstība vai radio saderības problēma šeit neizdodas, un klients parasti to pasaka. Otrais ir adreses piešķiršana: IPv4 gadījumā klients pieprasa nomu un saņem adresi kopā ar vietējiem vārtejas iestatījumiem, savukārt IPv6 parasti izmanto maršrutētāja paziņojumus DHCP vietā, kā apraksta AOSP tethering dokumentācija. Trešais ir izeja uz āru: resursdatora tālrunis pārsūta atļauto datplūsmu uz izvēlēto augšupējo ceļu, kas var būt vai nebūt tā tunelis.

Uzraksts klientā pasaka posmu. Iestrēgšana pie adreses iegūšanas ir otrais posms, pirms kāds pakete dodas uz internetu. Savienots, ar adresi, bet nekas neielādējas ir trešais posms, kur svarīga ir maršrutēšana, vārdi un tuneļa pārklājums. Diagnosticēt trešo posmu, kamēr klients iestrēdzis otrajā, ir veids, kā piecu minūšu nomas problēma kļūst par DNS rediģēšanas pēcpusdienu.

Mīts: maršrutēts VPN pārvērš vietējo DHCP attālinātā pieprasījumā

Maršrutēts tunelis pārvieto IP paketes tiem galamērķiem, ko tas izvēlas. DHCP atklāšana ir apraide paša hotspota segmentā, un tethering pakalpojums tālrunī uz to atbild lokāli, tāpēc klients var saņemt adresi, kamēr tunelis ir ieslēgts. Tikai apzināti tiltots vai pārsūtīts risinājums sūta šo apmaiņu citur, un tā ir cita konfigurācija ar citu kļūdas parakstu.

Tātad «VPN serveris neatbild uz DHCP» nav diagnoze, tā ir modeļa kļūda. Vietējais starpnieks ir tālrunī. Ja tas pārstāj atbildēt, iemesli ir vietēji: tethering pakalpojums, klientu limits, nomas baseins vai klients, kas nekad nav pareizi pabeidzis savienošanos. Neviens no tiem nedzīvo tuneļa tālajā pusē.

Ko faktiski pierāda strādājošs esošais klients

Ja portatīvais dators, kas jau bija savienots, joprojām strādā, bet jaunais tālrunis nē, hotspots un augšupējais ceļš kopumā ir dzīvi. Šis salīdzinājums ir noderīgs, un tas nav pierādījums, kura sastāvdaļa ir vainīga, jo strādājošais klients var vienkārši turēt nomu no pirms izmaiņām un klusi to atjaunot.

Ir vērts pārbaudīt divas vietējās robežas, kamēr esat tur. Hotspots apkalpo ierobežotu nomas baseinu un konfigurējamu klientu limitu, tāpēc ierīce, kas pievienojās un aizmiga, var turēt adresi, kamēr jauna gaida. Un klients, kas atceras statisku konfigurāciju no cita tīkla, nomu vispār neprasīs, kas no ārpuses izskatās identiski un tiek labots klientā, nevis tālrunī.

Turiet salīdzinājumu vietēju un atgriežamu

Ierīcē, kur politika to atļauj, salīdziniet vienu jauna klienta pievienošanos ar tuneli izslēgtu un pēc tam ieslēgtu, hotspotu un klientu citādi nemainot. Pierakstiet tālruņa un klienta versijas, izvēlēto profilu un precīzo posmu, kas neizdevās. Pārvaldītā tālrunī pieprasiet apstiprināto salīdzinājumu, nevis izslēdziet izpildi, lai iegūtu tīrāku testu.

Konsekventa no tuneļa atkarīga nomas kļūda ir noderīgs pierādījums par vietējo politiku vai ieviešanas mijiedarbību. Tā nav licence notīrīt katru pārsūtīšanas un NAT noteikumu ierīcē. Šie noteikumi aizsargā nesaistītu datplūsmu, un plaša pārsūtīšanas atļauja neizskaidro, kāpēc vietējais DHCP pakalpojums pārstāja atbildēt.

Neapsedziet trūkstošo nomu ar minētu statisku adresi. Apzinātai statiskai konfigurācijai vajadzīgs īstais apakštīkls, vārteja, sadales plāns un sadursmju pārbaude. Klienta DNS maiņa neko no tā nedod, un tā atstāj nākamo ierīci ar to pašu kļūdu.

Ko noma nepierāda

Adreses iegūšana pierāda uzņemšanu vietējā tīklā, nevis aizsardzību ar tālruņa tuneli. Kad klientam ir noma, novērtējiet lejupējo ceļu atsevišķi: vai klienta datplūsma tiešām iet caur tālruni, vai vaicājumi tiek atrisināti tur, kur gaidāt, un vai ārējā adrese atbilst paredzētajai izejai? Tie ir trešā posma jautājumi, un tiem pienākas savs tests, nevis salocīšana pievienošanās iekšienē.

Strādājiet pa posmiem pēc kārtas, un kļūda pārstās pārvietoties. Klients, kas iestrēdzis pie adreses iegūšanas, ir vietējs tethering jautājums; klients ar adresi un bez lapām ir pārsūtīšanas vai nosaukumu jautājums; klients ar lapām un nepareizu izeju ir tuneļa pārklājuma jautājums. To nošķiršana ir lielākā atkļūdošanas daļa.