OpenVPN punon në shtëpi por jo në një rrjet: UDP apo TCP?

I njëjti profil lidhet nga shtëpia dhe ngec në një rrjet hoteli, kampusi ose dege. Kredencialet nuk ndryshuan, prandaj variabla interesante është rruga: OpenVPN çfarë u ndodh paketave përpara se t'i lexojë. Krahasimi i katër shkaqeve të mundshme sipas rendit në të cilin mund të testohen është më mirë sesa hamendja për certifikatat. Secili lë një gjurmë të ndryshme, dhe gjurma është ajo që i ndan.

Cila fazë dështoi tregon se cili krahasim ka rëndësi

Regjistri i klientit tashmë shënon sa larg keni shkuar. Një rresht që thotë se negociimi i çelësit TLS nuk ndodhi brenda afatit kohor do të thotë që një paketë e parë doli dhe asgjë e përdorshme nuk u kthye, gjë që tregon rrugën. Refuzimi i certifikatës duket krejt ndryshe: mbërrin një përgjigje, pastaj një gabim specifik verifikimi emërton arsyen. Shënoni rreshtin e fundit përpara ciklit të ripërpjekjes, sepse ai është vlera që krahasoni midis rrjeteve.

Kapni gjatë ripërpjekjes, jo pas saj. Në klient tcpdump -ni any udp port 1194 tregon nëse kthehet fare ndonjë përgjigje. Përsëriteni në ndërfaqen WAN të një serveri që ju kontrolloni, gjë që zbulon nëse ato paketa arrijnë fare në skajin e largët.

Trafiku njëdrejtimësh është rezultati më i dobishëm i disponueshëm këtu, sepse e kthen një ankesë të herëpashershme në një drejtim hetimi. Ruani skedarët e kapjes, sepse raporti i ardhshëm i të njëjtit problem mbyllet më lehtë me prova sesa me një përshkrim.

Filtrimi UDP kundrejt një porte të mbyllur

Shumë rrjete aksesi e konsiderojnë UDP të vazhdueshme si të dyshimtë, dhe disa ISP bien dakord. Një portë e mbyllur prodhon të njëjtën heshtje nga ana e klientit. Dallimi është selektiviteti: një filtër priret të jetë i zgjedhur për atë se cilat destinacione ose porta hedh, ndërsa një portë e mbyllur refuzon gjithçka që drejtohet drejt asaj porte.

Një profil TCP në portën 443 është zgjidhja e zakonshme, sepse i ngjan një rrjedhe normale HTTPS dhe kalon nëpër shumicën e portaleve captive dhe filtrave të daljes. Duhet të plotësohen dy kushte. Serveri duhet të dëgjojë me proto tcp-server dhe klienti duhet të përputhet me proto tcp-client, dhe operatori duhet të publikojë atë pikë fundore alternative. Rishkrimi i një profili UDP që funksionon për të pretenduar TCP 443 nuk çon askund kur në anën tjetër nuk dëgjon askush.

Një portë e mbyllur është problem konfigurimi, jo problem censure. Një server pas një routeri shtëpiak ka nevojë për përcjelljen e portës UDP, dhe firewalls i routerit duhet ta lejojë atë. Kur porta nuk është lejuar kurrë, çdo klient dështon në negociim pavarësisht kredencialeve, dhe dështimi ndjek serverin dhe jo rrjetin.

Protokollet më të vjetra dalin keq në këtë aks. PPTP kërkon TCP 1723 plus GRE, dhe GRE është protokoll IP 47, jo portë, prandaj asnjë përcjellje e zakonshme porte nuk e shpreh atë.

Kur switch është ai që i hedh paketat

Një switch i menaxhuar mund ta hedhë tunelin me qëllim. Disa modele HPE dhe Aruba ofrojnë një kontroll mbrojtjeje nga përmbytja UDP, ndonjëherë të etiketuar Prevent UDP Blat Attack, në seksionin e sigurisë së avancuar. Sapo ai kontroll është aktiv, një server pas switch nuk përgjigjet për asgjë dhe çdo klient skadon në të njëjtën mënyrë. Fikja e tij dhe ruajtja e konfigurimit që funksionon është i gjithë riparimi, por vetëm pasi të keni vërtetuar se switch është vërtet në rrugë.

Provat kundër janë ajo që e ndan hedhjen nga switch nga bllokimi i ofruesit. Lexoni numëruesit e ndërfaqes dhe regjistrin e mbrojtjes nga përmbytja përpara se të hapni një tiketë te ISP. Routerët e konsumatorit me mbrojtje DoS ose nga përmbytja dështojnë në të njëjtën formë, dhe po ashtu çdo middlebox me afat të shkurtër të papunësisë UDP. Një shtrëngim duarsh që nuk përfundon kurrë sugjeron një hedhje, ndërsa një tunel që vdes pas minutash heshtjeje sugjeron afatin kohor.

Shkruani çdo pajisje midis klientit dhe serverit përpara se të ndryshoni një profil. Një rregullim i aplikuar në shtresën e gabuar duket i saktë deri në rrjetin tjetër. Ai listë i tregon edhe inxhinierit tjetër ku të shohë pa përsëritur të gjithë hetimin.

Një mbivendosje adresash që duket si dështim DNS

Një rrjet aksesi i numëruar brenda 10.0.0.0/8 mund të mbivendoset me pishinën e tunelit, dhe resolveri zakonisht jeton brenda asaj pishine. Kur një laptop merr një adresë si 10.184.178.50 me maskë /8 në Wi-Fi, çdo destinacion 10.x është lokal sipas përkufizimit. Paketat për 10.4.0.1 pastaj shkojnë në LAN, tuneli qëndron lart dhe zgjidhja e emrave dështon.

ip addr e zbulon mbivendosjen me një shikim, dhe ip route get 10.4.0.1 tregon ku paketa do të dorëzohej vërtet. Meqenëse simptoma e dukshme është një dështim i resolverit, kjo shpesh i mbijeton disa raundeve të ndryshimeve të DNS.

Rinumëroni pishinën ose mbajeni atë rrjet aksesi jashtë fushës. Asnjë cilësim nga ana e klientit nuk shërohet nga një mbivendosje.

Zgjedhja midis rrugës rezervë TCP dhe rregullimit të rrugës

Zgjidhni rrugën rezervë TCP kur nuk e kontrolloni rrugën dhe përdoruesit duhet të punojnë sot, dhe pranoni kostot e saj: TCP brenda TCP sillet keq në lidhje me humbje, dhe rruga rezervë kërkon një listener që e operoni ju. Zgjidhni rregullimin e rrugës kur bllokimi qëndron në infrastrukturën tuaj, sepse një rregull firewalls është më i lirë se një listener i dytë. Sido që të jetë, kaloni nëpër shtresat sipas radhës: lidhja, transporti i jashtëm, negociimi, rrugëtimi i brendshëm. Faza që dështoi në atë rrjet është fakti i vetëm që ka rëndësi.

Regjistroni rezultatin për rrjet, jo për përdorues. Raporti i ardhshëm i të njëjtit dështim pastaj nis nga një fazë e njohur në vend të një teorie certifikatash. Ai regjistrim është gjithashtu ajo që justifikon një listener të dytë të përhershëm, nëse nevojitet ndonjëherë.