Handshake ir, interneta nav: ko vispirms labot Windows 11

Windows 11 bieži jauni handshake atrodas blakus pārlūkiem, kas neko neatver. Handshake pierāda tikai to, ka UDP apmaiņa ar partneri ir pabeigta. Tas neko nepasaka par maršrutu, ko ievietoja Windows, par izmantoto resolveri, ne arī par to, vai izeja vispār kaut ko pārsūta.

Četri nosacījumi nosaka, kurš no šiem slāņiem neizdevās. To pārbaude pēc kārtas aizņem minūtes, kamēr atslēgu pārrakstīšana aizņem ilgāk un neko nemaina.

Nosakiet slāni, pirms aiztiekat atslēgas

Izejiet trīs galamērķus šajā secībā. Sāciet ar adresi tuneļa pusē, pēc tam publisku IP kā skaitli, un beidziet ar resursdatora nosaukumu. Tur, kur ķēde pārtrūkst, tur tiek nosaukts slānis. Pirmā soļa neveiksme ir maršrutēšana, otrajā tā ir pārsūtīšana vai NAT, bet trešajā – nosaukumu atrisināšana.

Šī secība ir visa metode. Tā neļauj DNS defektu diagnosticēt kā salauztu tuneli, kas šeit ir visbiežākais nepareizais pagrieziens.

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

Ja handshake laiks ir tukšs

Kad handshake laiks ir tukšs, šifrētā apmaiņa nekad nav pabeigta. Tāpēc defekts atrodas agrāk par maršrutēšanu. Vispirms apskatiet galapunkta adresi un portu, pēc tam to, vai tīkls filtrē UDP. Mitināšanas pakalpojumu sniedzējs, kas izmet WireGuard satiksmi, rada tieši to, un arī klients, kas nokopēja galapunktu no veca profila.

Baiti, kas iziet, bet neviens neienāk, ir cits gadījums. Tas norāda uz NAT vai ugunsmūri, kas atgriež satiksmi nepareizajā vietā.

Ja maršruts zaudē fiziskajam adapterim

Pilnam tunelim partnera sadaļai jāaptver galamērķi, ko plānojat izmantot. Windows dažreiz saglabā fiziskā adaptera noklusējuma maršrutu pat tad, ja ir iestatīts visu aptverošs noteikums. Visu aptverošā noteikuma sadalīšana 0.0.0.0/1 un 128.0.0.0/1 rada divus konkrētākus prefiksus, kas uzvar meklēšanā. Sadalīšana ir dokumentēts apvedceļš, nevis izvēle.

Apstipriniet to ar route print vai publiskas adreses meklēšanu. Izvēlētajai saskarnei jābūt tuneļa adapterim. Ja fiziskais joprojām uzvar, izlabojiet partnera diapazonus, pirms aiztiekat serveri.

Ja adreses darbojas un nosaukumi neizdodas

WireGuard pārsūta IP paketes un tam nav viedokļa par DNS. Ievietojiet DNS = rindu saskarnes sadaļā vai iestatiet adapteri caur Windows. Bez tās ping uz adresi izdodas, kamēr katrs resursdatora nosaukums neizdodas, un lietotāji to ziņo kā interneta neesamību.

Pārbaudiet, kurus serverus Windows patiešām izmanto pēc savienojuma. Fiziskajā adapterī palicis resolveris izskaidro daļēju neveiksmi, kad daži nosaukumi tiek atrisināti, bet citi ne. Iztīriet to, tā vietā lai virsū liktu otru.

Ja Windows dators ir izeja

Internet Connection Sharing pārraksta adresāciju, kad tas ir ieslēgts, un tas var pārvietot koplietoto adapteri uz citu diapazonu. Klients, kas joprojām rāda uz sākotnējo adresi, tad pārstāj darboties. Reģistra vērtības ScopeAddress un StandaloneDHCPAddress kontrolē šo diapazonu, un iestatījums var atgriezties pēc restartēšanas.

Ir vērts apskatīt vēl divus Windows raksturīgus konfliktus. Pakalpojums Routing and Remote Access var traucēt tunelim. Instalētājs, kas būvēts nepareizai arhitektūrai, neizdodas ar ziņojumu, kas nekad nemin arhitektūru.

Izlabojiet slāni, ko nosauca tests, un pēc tam vēlreiz izpildiet tos pašus trīs galamērķus. Izmaiņa, kas salabo resursdatora nosaukuma testu, bet salauž tuneļa adresi, tika piemērota nepareizajam slānim.