WAN-IP vaihtui ja tunneli katkesi: tarkistukset järjestyksessä

Tunneli katkeaa, reititin kirjaa uudelleenyhdistämisen, eikä lähiverkossa mikään liikkunut. Uusi WAN-osoite mitätöi ulkoisen yhteyden muuttamatta sisällä mitään: asiakkaan lähdeosoite on muuttunut, vanha NAT-tila osoittaa lähteeseen, jota ei enää ole, ja etävertais voi yhä lähettää edelliseen osoitteeseen. Palautuminen on normaalia käyttäytymistä, ja hyödyllinen kysymys on, mikä tila jäi päivittämättä.

Nimeä tapahtuma ennen kuin luet lokia

Selvitä, mitä liittymätasolla todella tapahtui. Palveluntarjoajan vuokrasopimuksen uusiminen on yksi tapahtuma. Uudelleen yhdistänyt PPPoE-istunto on toinen. Uudelleenkäynnistetty kuitumodeemi tai WAN-siirto yhdeltä yhteydeltä toiselle muuttaa ulkoista osoitetta tai sen reittiä kolmannella tavalla. Ne eivät ole sama tapahtuma eivätkä jätä samaa jäännöstä.

VPN-lokin uudelleenyhdistämisrivi ei sekään todista WAN-muutosta. Joutokäynnin aikakatkaisu, uudelleentodennuksen väli ja kuolleen vertaisen tunnistus tuottavat kaikki uudelleenyhdistämisiä ilman minkäänlaista osoitteen muutosta. Vertaa käyttölokin aikaleimoja VPN-lokiin ennen johtopäätöksiä ja pidä vertailuikkuna riittävän leveänä, jotta yöllä tapahtunut muutos jää siihen.

Roaming ja uudelleenyhdistäminen ovat eri protokollia

WireGuardissa on todennettu roaming sisäänrakennettuna protokollaan: kun vertais vastaanottaa oikein todennetun paketin uudesta lähdeosoitteesta, se päivittää kyseisen vertaisen päätepisteen. WireGuardin pikaopas kuvaa vertaiskonfiguraation, joka mahdollistaa tämän, minkä vuoksi vaihtuvassa osoitteessa oleva asiakas usein palautuu ilman näkyvää uudelleenkäynnistystä.

OpenVPN käyttäytyy oletuksena eri tavalla. UDP-istunto voi päättyä ja yhdistyä uudelleen, ja valinnainen float-käyttäytyminen sallii todennetun vertaisen jatkaa uudesta osoitteesta silloin, kun kokoonpano sen sallii. TCP-pohjaiset tunnelit ovat tiukempia, koska itse yhteys on sidottu osoitepariin. Tämä ero ratkaisee, näyttääkö palautuminen näkymättömältä vai ilmoittaako se itsestään lokissa joka kerta.

Kumpikaan käyttäytyminen ei kerro mitään sisällä olevista sovelluksista. Palautettu tunneli ei palauta TCP-istuntoa, jota vertais piti jo kuolleena.

Tila, jota tunneli ei omista

Käännös- ja reititystila selviää uudelleenyhdistämisestä tavoilla, jotka yllättävät ihmiset. Vanhalle lähteelle luotu conntrack-merkintä pitää vastauspolun ankkuroituna osoitteeseen, jota ei enää ole, ja se vanhenee oman aikataulunsa mukaan, ei silloin kun tunneli palasi. Tunnelipalvelun uudelleenkäynnistys ei lyhennä sitä odotusta, joten korjattu linkki voi näyttää rikkinäiseltä vielä hetken.

Reitit ja käytäntösäännöt voivat viitata vanhaan yhdyskäytävään tai liitäntään. Ennen WAN-vaihtoa oikea sääntöjoukko voi osoittaa laitteeseen, joka on nyt alhaalla, mikä tuottaa tunnelin, joka ilmoittaa olevansa yhteydessä, ja liikennettä, joka ei mene minnekään. Dynaaminen DNS palvelimelle, jota ylläpidät, on erillinen ongelma asiakkaasta, joka saa uuden lähteen. Tietue on päivitettävä, jotta etäasiakkaat löytävät sinut, eikä mikään asiakaspuolen kokoonpano korvaa osoitetta, jota ylävirran käännös ei välitä eteenpäin.

Järjestä tarkistukset ulkoa sisäänpäin

Alla oleva järjestys etenee ulkoyhteydestä sisäänpäin, ja pysähtyminen ensimmäiseen epäonnistuvaan vaiheeseen tekee siitä hyödyllisen: jokainen kierros sulkee pois yläpuolisen kerroksen. Pidä tämä järjestys, vaikka vika näyttäisi ilmeiseltä.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Ensimmäinen komento näyttää kunkin vertaisen nykyisen päätepisteen ja kättelyn iän. Toinen ja kolmas näyttävät, ovatko ulkoinen liitäntä ja reitti päätepisteeseen vielä järkeviä. conntrack-luku on karkea tarkistus edellisestä osoitteesta jääneelle tilalle, ja loki on paikka, johon uudelleenyhdistämisen syy kirjataan.

Testaa sitten lähiverkon asiakkaasta eikä reitittimestä. Reitittimen itsensä lähettämä ping käyttää eri polkua kuin välitetty liikenne, joten onnistunut reitittimen ping todistaa tunnelin olemassaolon eikä mitään asiakkaan tavoitettavuudesta.

Päätä odotettu käyttäytyminen ja kirjoita se muistiin

Uudelleenyhdistäminen on oikeaa käyttäytymistä useimmissa käyttöönotoissa, joten tavoitteena ei ole estää sitä. Päätä sen sijaan, mitä liikenteelle pitäisi tapahtua katkoksen aikana: pysäytetäänkö se, pidätetäänkö se vai siirrytäänkö toiselle polulle. Se päätös kuuluu palomuuriin ja reitityskäytäntöön, ei VPN-profiiliin.

Kirjaa käyttötapahtumat ja uudelleenyhdistämisajat yhdessä viikon ajan. Toistuvat muutokset ilman vastaavaa käyttötapahtumaa viittaavat käyttöpalveluun, eikä VPN-profiilin vaihtaminen korjaa yhteyttä, joka neuvottelee jatkuvasti uudelleen. Yksi merkintäpari samassa minuutissa ratkaisee kysymyksen kyseisen tapauksen osalta ja antaa seuraavalle lähtötason.