WireGuard darbojas uz mobilajiem datiem, bet ne tajā pašā wifi tīklā
Pieprasījums no LAN iekšpuses uz maršrutētāja publisko adresi iet citu ceļu nekā pieprasījums pa mobilajiem datiem. Pārbaudiet no ārpuses un pēc tam izvēlieties vietējo ceļu.
Tunelis paceļas uz mobilajiem datiem un pēc tam mājās paliek pie savienošanās, ar to pašu profilu, to pašu peer atslēgu un bez konfigurācijas izmaiņām starp. Atšķirība ir ceļā: pieprasījums no LAN iekšpuses uz maršrutētāja publisko adresi nav tas pats ceļojums kā pieprasījums, kas nāk no interneta. Lielākā daļa mājas vārteju vai nu vispār neievieš atgriešanās ceļu, vai ievieš to tikai noteiktiem protokoliem. Tāpēc simptoms izskatās kā salauzta atslēga, lai gan atslēgā nekas nav mainījies. Nosakiet, kurš ceļš neizdevās, pirms aiztiekat atslēgu, porta pāradresāciju vai klienta profilu.
Viena adrese, divi dažādi ceļi
No ārpuses pakete sasniedz maršrutētāja publisko adresi, un porta pāradresācijas noteikums to nodod WireGuard klausītājam iekšējā resursdatorā. No iekšpuses klients izsauc to pašu publisko adresi, tāpēc pakete atstāj klientu, sasniedz maršrutētāju un tai jābūt pagrieztai atpakaļ uz LAN pusi. Tieši šajā pagriezienā abi ceļi atšķiras, jo maršrutētājam ir jāpārtulko plūsma, kas vienlaikus iziet un atkal ieiet pa to pašu saskarni. Daudzas implementācijas to izmet, nevis pārtulko, un klients pēc tam gaida rokasspiedienu, kas nekad netika nosūtīts.
Šādu uzvedību parasti sauc par NAT loopback vai hairpinning, un tā pieder maršrutētājam, nevis WireGuard; RFC 4787 apraksta tulkošanas gadījumus, kuros vārteja to var atbalstīt vai ne. Pats WireGuard par ceļu neizsaka viedokli, jo redz tikai paketes, kas sasniedz tā saskarni. Kad maršrutētājs plūsmu izmet, dēmons nekad neko nesaņem, klients ziņo par rokasspiediena taimautu, un servera žurnāls paliek tukšs. Tukšs žurnāls tāpēc ir norāde, kur pakete apstājās, nevis pierādījums, ka serveris ir nokritis. Tas ir arī iemesls, kāpēc pārinstalēšana neko nemaina.
Arī pretējais ir svarīgi: servera žurnāls, kas parāda rokasspiediena mēģinājumu no LAN adreses, pierāda, ka pakete ieradās un ceļš ir kārtībā, kas pārvirza izmeklēšanu uz atslēgām un atļautajām adresēm. Lasiet žurnālu par to, ko tas pierāda, nevis par to, ko cerējāt ieraudzīt.
Vispirms atveidojiet, tad mainiet
Pārbaudiet no autorizēta ārēja tīkla ar to pašu ierīci un to pašu profilu, pēc tam atkārtojiet testu LAN iekšienē, neko nerediģējot. Pabeigts rokasspiediens ārpusē un klients, kas iekšienē nekad neatstāj ierīci, stāvokli atveido, nevis to min. Abiem mēģinājumiem jāizmanto viens un tas pats profils, citādi salīdzinājums neko nepierāda.
Pēc tam apskatiet, uz ko šai ierīcei atrisinās galapunkta nosaukums. Šīs trīs komandas arī parāda, kuru adresi klients faktiski izsauca:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netPirmā komanda ziņo galapunktu, ko saskarne pašlaik izmanto, un pārējās divas parāda, uz ko nosaukums atrisinās šajā mašīnā. Klients, kas izsauc publisko adresi, atrodoties tajā pašā tīklā kā serveris, izmanto hairpin ceļu. Klients, kas izsauc LAN adresi, to nedara, un kļūme tur pieder citai izmeklēšanai. Šī atšķirība izšķir, vai nākamā sadaļa vispār attiecas.
Atbalstītie veidi, kā sasniegt tuvējo serveri
Vistīrākais izkārtojums ir atbilde ar sadalītu horizontu: publiskais nosaukums atrisinās uz publisko adresi internetam un uz servera LAN adresi klientiem iekšpusē. Profils tur vienu galapunkta nosaukumu, un atrisinātājs izvēlas ceļu. Tas prasa kontroli pār iekšējo DNS atbildi, ko mājas maršrutētājs parasti piedāvā un organizācija var apzināti sakārtot. Bez šīs kontroles paliek maršrutētāja funkcija vai otrs profils.
Maršrutētāja funkcija ir atspulgs: vārteja pārtulko plūsmu no iekšpuses uz ārpusi un nosūta to atpakaļ iekšā. Kur tā darbojas, klienta izmaiņas nav vajadzīgas, un kur tā nedarbojas, neviena klienta iestatīšana to neglābs. Pārbaudiet to, vērojot servera žurnālu iekšēja mēģinājuma laikā, nevis lasot maršrutētāja funkciju sarakstu.
Profila maiņa uz privātu adresi ir diagnostika, nevis projekts. Tā pierāda, ka serveris atbild LAN tīklā, un salauž to pašu profilu tajā brīdī, kad klēpjdators izbrauc no mājām.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
Saglabājiet profilu lietojamu ārpus mājām
Lai kādu ceļu jūs izvēlētos, atstājiet identitātes pārbaudi mierā. Galapunkta adrese nav peer identitāte, un adreses maiņa nekad neattaisno svešas publiskās atslēgas, kas nejauši atbild, pieņemšanu. WireGuard autentificē ar atslēgu, tāpēc nepareizs resursdators neiztur rokasspiedienu, nevis dod piekļuvi kaut kam negaidītam.
Ja publiskā adrese pārvietojas, dinamiskais DNS ir tas, kas uztur nosaukumu noderīgu, un klienta atsvaidzināšanas uzvedība izšķir, cik ātri izmaiņa nonāks. Pārbaudiet to no ārpuses pēc adreses maiņas, jo LAN gadījums to nevar apstiprināt. Uzmanieties no atrisinātāja, kas kešatmiņā glabā veco atbildi ilgāk par ieraksta dzīves laiku. Nosaukums, kas joprojām norāda uz iepriekšējo adresi, izskatās tieši kā nokritis serveris.
Pierakstiet, kuru nosaukumu profils izmanto un uz ko tas atrisinās katrā robežas pusē. Profils, kas atkarīgs no maršrutētāja funkcijas, kuru neviens nav pierakstījis, ir atbalsta zvans, kas gaida nākamo programmaparatūras atjauninājumu. Pieraksts arī pasaka nākamajam cilvēkam, vai iekšēja kļūme ir zināmais hairpin gadījums vai kaut kas jauns.