VPN izveido savienojumu, bet LAN ierīces nav sasniedzamas: ko pārbaudīt

Datplūsma ieiet tunelī, vārteja atbild uz savu adresi, un nekas aiz tās neatbild. Šis modelis ir izplatīts un nav pretruna: atbilde no vārtejas pierāda, ka tunelis ir beidzies, un tā nepierāda neko par to, kas notiek ar paketi, kas adresēta aiz tās. Abi testi izmanto dažādus koda ceļus tajā pašā mašīnā.

Turpmāk pārbaudiet kaut ko vārtejas otrā pusē. Vārtejas pašas adrese turpinās atbildēt, lai cik bojāta būtu pāradresācija.

Vārteja atbild no sava steka

Pakete, kas adresēta vārtejai, tiek piegādāta tās lokālajam ievades ceļam, kur kodols izlemj, vai to pieņems klausošs ligzda. Pakete, kas adresēta resursdatoram aiz vārtejas, tā vietā tiek piegādāta pāradresācijas ceļam, kur ir spēkā cits pārbaužu kopums. Pāradresāciju var pilnībā izslēgt, vai arī kodols to ieslēdz un pēc tam to noraida filtra noteikums, kas nekad nemin tuneli. Nekas no tā neietekmē pašas vārtejas atbildi, tāpēc simptoms tik uzticami maldina.

Pārvaldības lapas, kas sasniegtas caur tuneli, arī pieder pirmajai kategorijai. Tās ir pierādījums par tuneli, nevis par tīklu aiz tā.

Sekojiet plūsmai līdz pirmajai robežai, kas to nomet

Sāciet ar klientu un apstipriniet maršrutu un avota adresi, ko plūsma izmantos. Pēc tam novērojiet vārteju, vai ierodas tieši šī plūsma, un vēlreiz to pašu plūsmu, kas dodas uz LAN. Ja tā nekad neierodas, problēma ir klienta pusē vai tuneļa atļautajos prefiksos. Ja tā ierodas un nekad neizbrauc, problēma ir pāradresācijā vai priekšējā ceļa filtrā, un ieraksts jau ir pateicis, kurā.

Tā paša testa izpilde no vārtejas paslēpj interesanto pusi, jo no vārtejas izcēlušās paketes avots un atgriešanās prasība ir citādi. Katrā solī izmantojiet klienta plūsmu ar tās pašas avota adresi. Nepareizā saskarnē veikts ieraksts dod pašpārliecinātu muļķību.

Atgriešanās maršruti un resursdatora ugunsmūri neizdodas atsevišķi

Kad pakete ir sasniegusi resursdatoru, jāizpildās vēl trim nosacījumiem. Pakalpojumam jāklausās adresē, uz kuru pakete tika nosūtīta, resursdatora ugunsmūrim tā jāpieņem, un atbildei jābūt ar atgriešanās maršrutu uz klientu kopu. Pēdējais bieži neizdodas, jo resursdatora noklusējuma maršruts norāda uz maršrutētāju, kas nekad nav dzirdējis par tuneļa diapazonu. Rezultāts ir savienojums, kas izveidojas no resursdatora viedokļa un klusi mirst otrā virzienā.

Apzināti pārbaudiet atgriešanās ceļu, sūtot no klienta un vērojot atgriešanos. Vienvirziena ieraksts sekundēs atrisina to, ko stunda minējumu neatrisinās.

Apstipriniet katru lēcienu ar klienta avota adresi

Izpildiet pārbaudes pēc kārtas un saglabājiet katru izvadi, jo vērtība ir salīdzinājumā, nevis vienā rindā. Tālāk minētās komandas nofiksē avota adresi, parāda izvēlēto maršrutu un ieraksta abas pāradresācijas puses. Aizstājiet savu LAN resursdatoru un tuneļa saskarni.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Maršruta vaicājums parāda, vai klients vispār sūtītu šo paketi tunelī, un ping parāda, vai kaut kas atgriezās no resursdatora. Divu ierakstu salīdzināšana atdala ierašanos no iziešanas, jo kadrs tuneļa saskarnē bez atbilstības LAN saskarnē ir pāradresācijas lēmums, nevis pakalpojuma kļūme. Kad abi ieraksti rāda pieprasījumu un tikai viens rāda atbildi, atlikušais aizdomās turamais ir atgriešanās maršruts.

Pierakstiet, kura adrese atbildēja un kurš pāradresētais mērķis neizdevās. Šis teikums padara ziņojumu darāmu, nevis apgalvojumu, ka serveris nav sasniedzams.