OpenVPN toimii kotona mutta ei yhdessä verkossa: UDP vai TCP?

Sama profiili yhdistää kotona ja pysähtyy hotelli-, kampus- tai sivukonttoriverkossa. Tunnukset eivät muuttuneet, joten kiinnostava muuttuja on reitti: mitä paketeille tapahtuu ennen kuin OpenVPN lukee ne. Neljän mahdollisen syyn vertaaminen siinä järjestyksessä, jossa ne voi testata, voittaa sertifikaateista arvaamisen. Jokainen jättää erilaisen jäljen, ja jälki on se, mikä erottaa ne.

Mikä vaihe epäonnistui kertoo, mikä vertailu ratkaisee

Asiakkaan loki kirjaa jo, kuinka pitkälle pääsit. Rivi, jonka mukaan TLS-avaimen neuvottelu ei tapahtunut aikarajan sisällä, tarkoittaa, että ensimmäinen paketti lähti eikä mitään käyttökelpoista tullut takaisin, mikä viittaa reittiin. Sertifikaatin hylkäys näyttää aivan erilaiselta: vastaus saapuu ja sitten tietty vahvistusvirhe nimeää syyn. Huomaa viimeinen rivi ennen uudelleenyrityssilmukkaa, sillä se on arvo, jota vertaat verkkojen välillä.

Kaappaa uudelleenyrityksen aikana, älä sen jälkeen. Asiakkaassa tcpdump -ni any udp port 1194 näyttää, tuleeko vastausta lainkaan takaisin. Toista se hallitsemasi palvelimen WAN-liitännällä, mikä paljastaa, pääsevätkö ne paketit lainkaan kauempaan päähän.

Yksipuolinen liikenne on hyödyllisin täällä saatavilla oleva tulos, koska se muuttaa ajoittaisen valituksen tutkittavaksi suunnaksi. Säilytä kaappaustiedostot, sillä seuraava samaa ongelmaa koskeva raportti on helpompi sulkea todisteilla kuin kuvauksella.

UDP-suodatus suljettua porttia vastaan

Monet käyttöverkkoympäristöt pitävät jatkuvaa UDP:tä epäilyttävänä, ja jotkut operaattorit ovat samaa mieltä. Suljettu portti tuottaa saman hiljaisuuden asiakkaan puolelta. Ero on valikoivuudessa: suodatin on usein nirso sen suhteen, mitkä kohteet tai portit se pudottaa, kun taas suljettu portti kieltää kaiken siihen yhteen porttiin kohdistuvan.

TCP-profiili portissa 443 on tavallinen kiertotie, koska se muistuttaa tavallista HTTPS-virtaa ja läpäisee useimmat captive-portaalit ja lähtösuodattimet. Kahden ehdon on täytyttävä. Palvelimen on kuunneltava proto tcp-server ja asiakkaan vastattava proto tcp-client, ja operaattorin on julkaistava se vaihtoehtoinen päätepiste. Toimivan UDP-profiilin kirjoittaminen uudelleen väittämään TCP 443 ei johda mihinkään, kun toisessa päässä ei kuuntele kukaan.

Suljettu portti on kokoonpano-ongelma eikä sensuuriongelma. Kotireitittimen takana oleva palvelin tarvitsee UDP-portin edelleenohjauksen, ja reitittimen palomuurin on sallittava se. Kun porttia ei koskaan sallittu, jokainen asiakas epäonnistuu neuvottelussa tunnuksista riippumatta, ja vika seuraa palvelinta eikä verkkoa.

Vanhemmat protokollat pärjäävät tällä akselilla huonosti. PPTP tarvitsee TCP 1723:n ja GRE:n, ja GRE on IP-protokolla 47 eikä portti, joten mikään tavallinen portin edelleenohjaus ei ilmaise sitä.

Kun kytkin on se, joka pudottaa paketteja

Hallittu kytkin voi pudottaa tunnelin tarkoituksella. Jotkin HPE- ja Aruba-mallit tarjoavat lisäasetusten suojausosiossaan UDP-tulvasuojauksen ohjaimen, joskus merkittynä Prevent UDP Blat Attack. Kun se ohjain on aktiivinen, kytkimen takana oleva palvelin ei vastaa mitään ja jokainen asiakas päättyy aikakatkaisuun samalla tavalla. Sen poistaminen käytöstä ja käynnissä olevan kokoonpanon tallentaminen on koko korjaus, mutta vasta sen jälkeen, kun olet todennut kytkimen todella olevan reitillä.

Vastalauseet ovat se, mikä erottaa kytkimen pudotuksen operaattorin estosta. Lue liitäntälaskurit ja tulvasuojauksen loki ennen kuin avaat tiketin operaattorille. Kuluttajareitittimet, joissa on DoS- tai tulvasuojaus, epäonnistuvat samalla tavalla, samoin mikä tahansa välilaite, jolla on lyhyt UDP:n lepoaikaraja. Kättely, joka ei koskaan valmistu, viittaa pudotukseen, kun taas tunneli, joka kuolee muutaman hiljaisen minuutin jälkeen, viittaa aikarajaan.

Kirjoita ylös jokainen laite asiakkaan ja palvelimen välillä ennen kuin muutat profiilia. Väärälle kerrokselle tehty korjaus näyttää oikealta seuraavaan verkkoon asti. Se luettelo kertoo myös seuraavalle insinöörille, mistä katsoa toistamatta koko tutkimusta.

Osoitteiden päällekkäisyys, joka näyttää DNS-vialta

Käyttöverkko, joka on numeroitu 10.0.0.0/8:n sisään, voi mennä päällekkäin tunnelialtaan kanssa, ja resolveri asuu yleensä siinä altaassa. Kun kannettava saa Wi-Fi:ssä osoitteen kuten 10.184.178.50 /8-maskilla, jokainen 10.x-kohde on määritelmän mukaan paikallinen. Paketit 10.4.0.1:lle menevät silloin lähiverkkoon, tunneli pysyy pystyssä ja nimien selvitys epäonnistuu.

ip addr paljastaa päällekkäisyyden yhdellä silmäyksellä ja ip route get 10.4.0.1 näyttää, minne paketti todella toimitettaisiin. Koska näkyvä oire on resolverin vika, tämä tapaus selviää usein useista DNS-muutosten kierroksista.

Numeroi allas uudelleen tai pidä se käyttöverkko alueen ulkopuolella. Mikään asiakaspuolen asetus ei palaudu päällekkäisyydestä.

Valinta TCP-varayhteyden ja reittikorjauksen välillä

Valitse TCP-varayhteys, kun et hallitse reittiä ja käyttäjien on päästävä töihin tänään, ja hyväksy sen kustannukset: TCP TCP:n sisällä käyttäytyy huonosti häviöllisillä yhteyksillä, ja varayhteys tarvitsee kuuntelijan, jota sinä ylläpidät. Valitse reittikorjaus, kun esto on omistamassasi infrastruktuurissa, koska palomuurisääntö on halvempi kuin toinen kuuntelija. Kummassakin tapauksessa käy kerrokset järjestyksessä läpi: linkki, ulompi kuljetus, neuvottelu, sisäinen reititys. Se vaihe, joka siinä verkossa epäonnistui, on ainoa merkitsevä tosiasia.

Kirjaa tulos verkkokohtaisesti, älä käyttäjäkohtaisesti. Saman vian seuraava raportti alkaa silloin tunnetusta vaiheesta sertifikaattiteorian sijaan. Se kirjaus myös perustelee pysyvän toisen kuuntelijan, jos sellaista koskaan tarvitaan.