OpenVPN strādā mājās, bet ne vienā tīklā: UDP vai TCP?

Tas pats profils savienojas mājās un apstājas viesnīcas, campus vai filiāles tīklā. Akreditācijas dati nav mainījušies, tāpēc interesantais mainīgais ir ceļš: kas notiek ar paketēm pirms OpenVPN tās nolasa. Salīdzināt četrus iespējamos cēloņus tādā secībā, kādā tos var pārbaudīt, ir labāk nekā minēt par sertifikātiem. Katrs atstāj citu pēdu, un tieši pēda tos atšķir.

Kurš posms neizdevās, nosaka, kurš salīdzinājums ir svarīgs

Klienta žurnālā jau ir ierakstīts, cik tālu jūs nonācāt. Rinda, ka TLS atslēgas saruna nenotika noteiktajā laikā, nozīmē, ka pirmais pakets aizgāja un nekas lietojams neatgriezās, kas norāda uz ceļu. Sertifikāta noraidījums izskatās pavisam citādi: atnāk atbilde, tad konkrēta verifikācijas kļūda nosauc iemeslu. Pierakstiet pēdējo rindu pirms atkārtošanas cikla, jo tieši šī vērtība ir jāsalīdzina starp tīkliem.

Uzņemiet, kamēr mēģināt vēlreiz, nevis pēc tam. Klientā tcpdump -ni any udp port 1194 parāda, vai vispār atgriežas kāda atbilde. Atkārtojiet to servera, kuru kontrolējat, WAN saskarnē – tas atklās, vai šie paketi vispār sasniedz tālo galu.

Vienpusēja plūsma ir šeit pieejamākais noderīgākais rezultāts, jo tā pārvērš periodisku sūdzību izmeklēšanas virzienā. Saglabājiet uzņemšanas failus, jo nākamo ziņojumu par to pašu problēmu ir vieglāk aizvērt ar pierādījumiem nekā ar aprakstu.

UDP filtrēšana pret slēgtu portu

Daudzi piekļuves tīkli uzskata ilgstošu UDP par aizdomīgu, un daži ISP tam piekrīt. Slēgts ports no klienta puses rada tādu pašu klusumu. Atšķirība ir selektivitāte: filtrs mēdz būt izvēlīgs attiecībā uz to, kurus galamērķus vai portus tas atmet, savukārt slēgts ports noraida visu, kas vērsts uz šo portu.

TCP profils 443. portā ir ierastais risinājums, jo tas atgādina parastu HTTPS plūsmu un iziet cauri lielākajai daļai captive portālu un izejas filtru. Ir jāizpildās diviem nosacījumiem. Serverim jāklausās ar proto tcp-server un klientam jāsakrīt ar proto tcp-client, un operatoram ir jāpublicē šis alternatīvais endpoint. Pārrakstīt strādājošu UDP profilu, apgalvojot, ka tas ir TCP 443, nekur nenoved, ja otrā galā nekas neklausās.

Slēgts ports ir konfigurācijas, nevis cenzūras problēma. Serverim aiz mājas maršrutētāja ir nepieciešama UDP porta pāradresācija, un maršrutētāja ugunsmūrim tas jāatļauj. Ja ports nekad nav ticis atļauts, katrs klients neizdodas sarunās neatkarīgi no akreditācijas datiem, un kļūme seko serverim, nevis tīklam.

Vecāki protokoli šajā asī salīdzinājumā izskatās slikti. PPTP nepieciešams TCP 1723 plus GRE, un GRE ir IP protokols 47, nevis ports, tāpēc parasta porta pāradresācija to neizsaka.

Kad komutators ir tas, kas izmet paketes

Pārvaldāms komutators var apzināti izmest tuneli. Daži HPE un Aruba modeļi piedāvā UDP flood aizsardzības kontroli, dažreiz marķētu Prevent UDP Blat Attack, savā paplašinātajā drošības sadaļā. Kad šī kontrole ir aktīva, serveris aiz komutatora neatbild uz neko un katrs klients iztukšojas laikā tādā pašā veidā. Notīrīt to un saglabāt darbojošos konfigurāciju ir viss remonts, bet tikai pēc tam, kad esat noskaidrojis, ka komutators tiešām ir ceļā.

Pretpierādījumi ir tas, kas atšķir komutatora izmetumu no pakalpojumu sniedzēja bloķējuma. Pirms biļetes atvēršanas pie ISP izlasiet saskarnes skaitītājus un flood aizsardzības žurnālu. Mājsaimniecības maršrutētāji ar DoS vai flood aizsardzību neizdodas tādā pašā formā, un tāpat jebkurš starpnieks ar īsu UDP dīkstāves limitu. Rokasspiediens, kas nekad nebeidzas, liecina par izmetumu, savukārt tunelis, kas nomirst pēc dažu minūšu klusuma, liecina par limitu.

Pirms profila maiņas pierakstiet katru ierīci starp klientu un serveri. Nepareizajā slānī lietots labojums izskatās pareizs līdz nākamajam tīklam. Šis saraksts arī pasaka nākamajam inženierim, kur skatīties, neatkārtojot visu izmeklēšanu.

Adrešu pārklāšanās, kas izskatās kā DNS kļūme

Piekļuves tīkls, kas numurēts 10.0.0.0/8 iekšpusē, var pārklāties ar tuneļa pūlu, un resolveris parasti dzīvo šajā pūlā. Kad klēpjdators Wi-Fi saņem adresi, piemēram, 10.184.178.50 ar /8 masku, katrs 10.x galamērķis pēc definīcijas ir lokāls. Paketes uz 10.4.0.1 tad dodas uz LAN, tunelis paliek augšā, un nosaukumu izšķiršana neizdodas.

ip addr atklāj pārklāšanos vienā mirklī, un ip route get 10.4.0.1 parāda, kur pakete patiešām tiktu piegādāta. Tā kā redzamais simptoms ir resolvera kļūme, šis bieži pārdzīvo vairākas DNS izmaiņu kārtas.

Pārnumurējiet pūlu vai turiet šo piekļuves tīklu ārpus darbības jomas. Nekāds klienta puses iestatījums neatgūstas no pārklāšanās.

Izvēle starp TCP rezerves ceļu un ceļa labošanu

Izvēlieties TCP rezerves ceļu, ja nekontrolējat ceļu un lietotājiem šodien jāstrādā, un pieņemiet tā izmaksas: TCP TCP iekšienē slikti uzvedas zūdošos savienojumos, un rezerves ceļam vajadzīgs jūsu pārvaldīts listener. Izvēlieties ceļa labošanu, ja bloķējums atrodas jums piederošā infrastruktūrā, jo ugunsmūra noteikums ir lētāks par otru listener. Jebkurā gadījumā ejiet cauri slāņiem secībā: saite, ārējais transports, sarunas, iekšējā maršrutēšana. Posms, kas šajā tīklā neizdevās, ir vienīgais svarīgais fakts.

Reģistrējiet rezultātu pa tīkliem, nevis pa lietotājiem. Nākamais ziņojums par to pašu kļūmi tad sākas no zināma posma, nevis no sertifikāta teorijas. Šis ieraksts arī attaisno pastāvīgu otru listener, ja tāds kādreiz būs vajadzīgs.