Jūs atverat klēpjdatoru viesnīcas istabā, palaižat klientu, ierakstāt iekšējā failu servera nosaukumu un nesaņemat neko. Tunelis ziņo, ka ir savienots, un ping uz adresi tajā pašā apakštīklā joprojām atbild, tātad pats transports ir kārtībā. Neizdodas tikai nosaukums, un šī plaisa sašaurina problēmu līdz divām vietām: kuru risinātāju klients jautāja un vai saņemtā atbilde var atgriezties pa tuneli. Izlabojiet vienu un izlaidiet otru, un kļūda vienkārši pārvietojas.

Pirms rediģējat jebkuru profilu, pārbaudiet, ko klients dara ar nosaukumu. Linux sistēmā resolvectl query files.corp.example parāda, kurš savienojums un kurš risinātājs radīja atbildi. Windows sistēmā Resolve-DnsName files.corp.example parāda serveri, kas atbildēja, un adresi, ko tas atgrieza.

Izlasi atbildi, pirms kaut ko maini

Ja nosaukums atgriežas kā NXDOMAIN dažu milisekundu laikā, vaicājums nekad nesasniedza jūsu zonu un tā vietā atbildēja kāds publisks vai viesnīcas risinātājs. Ja tas atgriežas pēc ilgas pauzes, kaut kas pa ceļam izmet UDP portu 53 un klients beigās pārgāja uz rezervi. Ja tas atbild ar pareizo adresi, bet savienojums joprojām iesprūst, meklēšana ir kārtībā un jūsu problēma ir maršrutēšanā vai pašā pakalpojumā.

Šis sadalījums trīs daļās ietaupa stundu minējumu. Tas arī pasaka, vai VPN vispār jāaiztiek: nosaukums, kas atrisinās uz pareizo privāto adresi, jau ir pierādījis risinātāja ceļu, tāpēc atlikušais darbs ir datu ceļā.

Izsniedz risinātāju no tuneļa iekšpuses

Klienti iedalās divās grupās. Vienai serveris savienojuma izveides laikā var norādīt risinātāju; otra tur iestatījumu lokālā failā, ko neviena vārteja nevar mainīt attālināti.

OpenVPN ir pirmajā grupā. Serverī push "dhcp-option DNS 10.8.0.53" un push "dhcp-option DOMAIN corp.example" ceļo pa vadības kanālu, bet tikai tad, ja klienta konfigurācijā joprojām ir iespējots pull. Ar roku rediģēts klients ar pull-filter ignore "dhcp-option" tos nekad neredzēs, un šī vienīgā rinda izskaidro pārsteidzoši daudz gadījumu, kad serveris to spiež, bet mans klēpjdators nepiekrīt.

WireGuard ir otrajā grupā, jo protokolā vispār nav opciju apspriešanas. Risinātājs un meklēšanas domēns nonāk klienta paša [Interface] blokā kā DNS = 10.8.0.53, corp.example. wg-quick to piemēro caur resolvconf vai systemd-resolved, un Windows sistēmā oficiālais klients instalē NRPT noteikumus, kas pastāv tikai tik ilgi, kamēr tunelis ir uzcelts: Get-DnsClientNrptPolicy tos uzskaita, kas padara to par ātru veidu, kā redzēt, vai klients kādreiz ir piemērojis jūsu failu.

IPsec/IKEv2 atrodas pa vidu. strongSwan attr spraudnis var atgriezt DNS serveri, kas izvilkts no kopas, un Windows klients to parasti pieņem, bet profils, kas fiksē savu nosaukumu serveri, uzvar pār visu, ko vārteja piedāvā. Linux klientā līdzvērtīgais manuālais solis ir resolvectl dns wg0 10.8.0.53, kam seko resolvectl domain wg0 '~corp.example'; abi pazūd kopā ar saskarni, kas ir tieši tas, ko jūs vēlaties ar tuneli saistītam iestatījumam.

Ierobežo sufiksu, nevis aprīt katru vaicājumu

Visu klienta risinātāju sarakstu vērst uz jūsu iekšējo serveri ir viegli un parasti nepareizi. Tad katrs publiskais nosaukums atrisinās caur jūsu datu centra izeju, CDN atgriež tālas adreses, un viens risinātāja pārtraukums aizrauj līdzi lietotāja pārlūkošanu.

Sūti uz iekšu tikai privāto sufiksu. systemd-resolved domēns, kas sākas ar ~, ir tikai maršrutēšanai, tāpēc ~corp.example nozīmē, ka vaicājumi zem šī sufaksa dodas uz tā savienojuma serveriem, kamēr viss pārējais turpina izmantot fizisko tīklu. Windows dara to pašu ar NRPT noteikumiem, kas ierobežoti uz vārdu telpu, un macOS ar papildu risinātāja failu /etc/resolver/ mapē.

Multiraides nosaukumi pelna savu atbildi. .local nosaukumi pēc konstrukcijas ir link-local (RFC 6762), un punkts-punktā tun saskarne nenes šo multiraides grupu, tāpēc publiska risinātāja pievienošana tos nepublicēs, un, ja par tiem jautās iekšējam unicast risinātājam, atbilde būs NXDOMAIN. Reflektors, piemēram, avahi reflektora režīmā, var savienot divus segmentus, bet tas ir servera puses lēmums, ko neviens klients nevar pieprasīt. Ja printerim vai NAS ir jābūt sasniedzamam pēc nosaukuma, piešķiriet tam A ierakstu savā zonā.

Pierādi, ka atbilde var atgriezties

Pareiza atbilde, kas norāda uz nesasniedzamu adresi, izskatās tieši kā risinātāja problēma, līdz pārbaudāt maršrutu. Pajautājiet kodolam, kur atbilde dotos: ip route get 10.20.5.20 nosauc saskarni un, kas noderīgāk, avota adresi, ko tā izmantotu.

Vērojiet pašu risinātāja adresi. Klients ar DNS = 10.8.0.53 blakus AllowedIPs = 10.20.0.0/16 sūta savus vaicājumus pa fizisko tīkla karti, kur tie klusi nomirst, jo risinātājs neatrodas nevienā prefiksā, ko tunelis pieprasa. Šī neatbilstība ir visbiežākā vienotā cēloņa kļūda visā šajā jomā, un tā paliek neredzama, ja vien ne salīdzināt DNS iestatījumu ar atļautajiem prefiksiem rindu pa rindai.

Pārklājošies diapazoni izraisa pretēju kļūdu. Atbilde ir pareiza, maršruts pastāv, un tas norāda uz nepareizo resursdatoru, jo 192.168.0.0/24 mājās ir konkrētāks nekā tuneļa maršruts uz to pašu diapazonu. Pārnumurējiet vienu pusi vai izspiediet šaurāku maršrutu, pēc tam apstipriniet pakalpojuma resursdatora ugunsmūri un atgriešanās ceļu; strongSwan piezīmes par pāradresēšanu aptver šī ceļa sysctl pusi.

Sertifikāti ir atsevišķa identitātes pārbaude, ko cilvēki novelk uz DNS. Ja pārlūks ziņo par nosaukuma neatbilstību, nevis atrisināšanas kļūdu, meklēšana jau ir nostrādājusi, un labojams ir sertifikāta SAN. Pārbaudiet HTTPS pret nosaukumu, nekad pret kailo IP.

Pārbaudiet vēlreiz no klienta, nevis no vārtejas

Pārbaudiet lietotnē, par ko lietotājs sūdzas, jo meklēšana komandrindā nepierāda, ka pārlūks iet to pašu ceļu. Chrome drošais DNS un Firefox network.trr.mode var pilnībā apiet sistēmas risinātāju, un, kad tie to dara, privātais nosaukums vai nu neizdodas, vai noplūst uz publisku risinātāju. resolvectl query salīdzināšana ar manuāli palaistu dig @10.8.0.53 files.corp.example pasaka, kurš no diviem notika.

Pēc tam atvienojieties un pievienojieties vēlreiz, pirms saucat to par izlabotu. Saskarnei ar roku uzliktie iestatījumi pazūd kopā ar saskarni, un profils, kas izskatījās pareizi tikai aizmirstas lokālas izmaiņas dēļ, nokritīs nākamajā startā.

Īss kontrolsaraksts nākamajai mašīnai: nosaukums atrisinās pa tuneļa risinātāju, sufikss ir norobežots, nevis globāls, risinātāja adrese atrodas atļauto prefiksu iekšpusē, atbildes resursdators atbild pakalpojuma portā un sertifikāts nosedz lietotāja ierakstīto nosaukumu.

Saistītie raksti