OpenVPN veikia namuose, bet ne viename tinkle: UDP ar TCP?
Vienas tinklas blokuoja tunelį, kitas – ne. Palyginkite UDP filtravimą, komutatoriaus apsaugą nuo flood, TCP 443 atsarginį kelią ir adresų plano sutapimą.
Ta pati konfigūracija prisijungia namuose ir sustoja viešbučio, miestelio ar filialo tinkle. Prisijungimo duomenys nepasikeitė, todėl įdomus kintamasis yra kelias: kas nutinka paketams prieš OpenVPN juos perskaitant. Palyginti keturias galimas priežastis tokia tvarka, kokia jas galima išbandyti, geriau nei spėlioti apie sertifikatus. Kiekviena palieka skirtingą pėdsaką, ir būtent pėdsakas jas atskiria.
Kuris etapas nepavyko, parodo, kuris palyginimas svarbus
Kliento žurnale jau užfiksuota, kiek toli nuėjote. Eilutė, kad TLS rakto derybos neįvyko per numatytą laiką, reiškia, kad pirmas paketas išėjo ir nieko naudingo negrįžo, o tai rodo kelią. Sertifikato atmetimas atrodo visai kitaip: ateina atsakymas, tada konkreti tikrinimo klaida nurodo priežastį. Užsirašykite paskutinę eilutę prieš pakartojimų ciklą, nes būtent šią reikšmę lyginsite tarp tinklų.
Fiksuokite bandydami iš naujo, o ne po to. Kliente tcpdump -ni any udp port 1194 parodo, ar apskritai grįžta koks nors atsakymas. Pakartokite tai savo valdomo serverio WAN sąsajoje – tai atskleis, ar tie paketai apskritai pasiekia tolimąjį galą.
Vienpusis srautas yra naudingiausias čia gaunamas rezultatas, nes jis nepastovų nusiskundimą paverčia tyrimo kryptimi. Išsaugokite fiksavimo failus, nes kitą tos pačios problemos ataskaitą lengviau uždaryti įrodymais nei aprašymu.
UDP filtravimas prieš uždarą prievadą
Daugelis prieigos tinklų nuolatinį UDP laiko įtartinu, o kai kurie ISP tam pritaria. Uždaras prievadas iš kliento pusės sukuria tą pačią tylą. Skirtumas – selektyvumas: filtras linkęs būti išrankus, kuriuos tikslus ar prievadus jis numeta, o uždaras prievadas atmeta viską, kas nukreipta į tą prievadą.
TCP profilis 443 prievade yra įprasta išeitis, nes jis primena įprastą HTTPS srautą ir praeina pro daugumą captive portalų ir išėjimo filtrų. Turi būti įvykdytos dvi sąlygos. Serveris turi klausytis su proto tcp-server, o klientas turi atitikti proto tcp-client, ir operatorius turi paskelbti tą alternatyvų endpointą. Perrašyti veikiantį UDP profilį teigiant TCP 443 nieko neduoda, kai kitame gale niekas neklauso.
Uždaras prievadas yra konfigūracijos, o ne cenzūros problema. Serveriui už namų maršrutizatoriaus reikia persiųsti UDP prievadą, o maršrutizatoriaus ugniasienė turi tai leisti. Kai prievadas niekada nebuvo leistas, kiekvienas klientas nepavyksta derybose nepriklausomai nuo prisijungimo duomenų, o gedimas seka serverį, o ne tinklą.
Senesni protokolai šioje ašyje atrodo prastai. PPTP reikia TCP 1723 plius GRE, o GRE yra IP protokolas 47, o ne prievadas, todėl įprastas prievado persiuntimas to neišreiškia.
Kai komutatorius numeta paketus
Valdomas komutatorius gali sąmoningai numesti tunelį. Kai kurie HPE ir Aruba modeliai išplėstinės saugos skiltyje siūlo UDP flood apsaugos valdiklį, kartais pažymėtą Prevent UDP Blat Attack. Kai šis valdiklis aktyvus, komutatoriaus užpakalyje esantis serveris į nieką neatsako ir kiekvienas klientas baigiasi tuo pačiu laiko limitu. Jį išjungti ir išsaugoti veikiančią konfigūraciją – tai visas remontas, bet tik nustačius, kad komutatorius tikrai yra kelyje.
Priešingi įrodymai yra tai, kas atskiria komutatoriaus numetimą nuo teikėjo blokavimo. Perskaitykite sąsajos skaitiklius ir flood apsaugos žurnalą prieš atidarydami bilietą ISP. Buitiniai maršrutizatoriai su DoS ar flood apsauga nepavyksta taip pat, ir bet kokia tarpinė dėžė su trumpu UDP neveiklumo limitu. Niekada nepasibaigiantis rankos paspaudimas rodo numetimą, o tunelis, kuris miršta po kelių minučių tylos, rodo laiko limitą.
Užrašykite kiekvieną įrenginį tarp kliento ir serverio prieš keisdami profilį. Netinkamame sluoksnyje pritaikytas pataisymas atrodo teisingas iki kito tinklo. Tas sąrašas taip pat pasako kitam inžinieriui, kur žiūrėti, nekartojant viso tyrimo.
Adresų sutapimas, kuris atrodo kaip DNS gedimas
Prieigos tinklas, numeruotas 10.0.0.0/8 viduje, gali sutapti su tunelio telkiniu, o resolveris paprastai gyvena tame telkinyje. Kai nešiojamasis kompiuteris Wi-Fi gauna adresą, pavyzdžiui, 10.184.178.50 su /8 kauke, kiekvienas 10.x tikslas pagal apibrėžimą yra vietinis. Paketai į 10.4.0.1 tada eina į LAN, tunelis lieka veikti, o vardų sprendimas nepavyksta.
ip addr atskleidžia sutapimą iš karto, o ip route get 10.4.0.1 parodo, kur paketas iš tikrųjų būtų pristatytas. Kadangi matomas simptomas yra resolverio gedimas, šis dažnai išlieka po kelių DNS pakeitimų ratų.
Pernumeruokite telkinį arba laikykite tą prieigos tinklą už aprėpties. Joks kliento nustatymas neišgydo sutapimo.
Pasirinkimas tarp TCP atsarginio kelio ir kelio taisymo
Rinkitės TCP atsarginį kelią, kai nevaldote kelio ir vartotojams reikia dirbti šiandien, ir priimkite jo kaštus: TCP TCP viduje blogai elgiasi nuostolinguose ryšiuose, o atsarginiam keliui reikia jūsų valdomo listener. Rinkitės kelio taisymą, kai blokas yra jums priklausančioje infrastruktūroje, nes ugniasienės taisyklė pigesnė už antrą listener. Bet kuriuo atveju eikite per sluoksnius eilės tvarka: jungtis, išorinis transportas, derybos, vidinis maršrutizavimas. Etapas, kuris nepavyko tame tinkle, yra vienintelis svarbus faktas.
Fiksuokite rezultatą pagal tinklą, o ne pagal vartotoją. Kita to paties gedimo ataskaita tada prasideda nuo žinomo etapo, o ne nuo sertifikato teorijos. Tas įrašas taip pat pateisina nuolatinį antrą listener, jei jo kada prireiktų.