Sovellus sidottu liitäntään? Sen VPN-polku ei ole oletus

Yksi koneen sovellus lähtee VPN:n kautta ja toinen ei, ja molemmat käyttäjät vannovat, etteivät muuttaneet mitään. Ero on usein sovelluksen oma sidontapäätös: laitteeseen sidottu socket, ennen yhteyttä valittu lähdeosoite tai nimiavaruus, jolla on oma reititystaulunsa. Jokainen muuttaa sitä, mikä polku pätee, eikä mikään niistä näy selaimen yleisessä IP-tarkistuksessa.

Kolme erilaista sidontaa, kolme erilaista vaikutusta

Laitteeseen sitominen ja lähdeosoitteeseen sitominen ovat sukua olevia toimintoja, joiden seuraukset eroavat. Laitesidonta voi pakottaa liikenteen ulos yhdestä liitännästä ja ohittaa kyseisen socketin normaalin reittihaun. Lähdeosoitteen sidonta kulkee silti reitin valinnan kautta, mutta valittu lähde voi vastata käytäntösääntöä ja lähettää paketin muualle. Ero kuulostaa akateemiselta, kunnes sääntö reitittää lähteen mukaan. Silloin se ratkaisee kaiken.

Verkkonimiavaruus on kolmas tapaus. Sillä on omat liitäntänsä ja reititystaulunsa, joten sen sisällä olevaan sovellukseen isännän oletus ei vaikuta lainkaan. Jos kaikkia kolmea kohdellaan samana asiana, syntyy itsevarmoja selityksiä, jotka eivät kestä ensimmäistä testiä.

Selvitä, mitä sovellus todella asettaa

Lue sovelluksen verkkoasetukset tai sen dokumentoitu käyttäytyminen ennen kuin kosket reitteihin. Jos se tarjoaa liitännän valinnan, lähdeosoitekentän tai nimiavaruusvaihtoehdon, tuo asetus on ensimmäinen tarkistettava. Jos ei, sidonta voi olla sisäinen ja näkyä vain jäljityksen tai sen oman diagnostiikan kautta.

Linuxissa socket-asetuksilla kuten SO_BINDTODEVICE on dokumentoitu laajuus ja oikeusvaatimukset, eikä ei-privilegioitu prosessi välttämättä pysty asettamaan niitä lainkaan. Tämä rajoitus on hyödyllinen vihje: jos asetusta ei voi soveltaa, sovellus ei todennäköisesti ole eron lähde.

Käytäntöreititys lukee lähteen

Kun käytäntöreititys on määritetty, sääntö voi valita taulun paketin lähteen perusteella. Siksi lähdeosoitteen sitova socket voi seurata sääntöä, jota oletuspolku ei kosketa lainkaan, vaikka mitään liitäntää ei olisi nimetty erikseen.

Toista haku samalla osoiteperheellä, lähteellä ja nimiavaruudella, jota sovellus käyttää. Yleinen reittihaku isännän nimiavaruuden kuoresta vastaa eri kysymykseen, ja tämä ristiriita on yleisin syy siihen, että toimiva reitti näyttää rikkinäiseltä.

Jaettu tunneli ja apuprosessit

Sovelluskohtainen jaettu tunneli lisää yhden kerroksen. Asiakas voi sovittaa sovelluksen paketin tai prosessin, ja oman socketinsa avaava apuri on erillinen kohde. Käynnistin ja sen taustapalvelu voivat tuottaa erilaisia yhteyksiä saman näkyvän nimen alla.

Tarkista, kattaako jaetun tunnelin sääntö prosessin, joka todella yhdistää. Jos sovellus sitoutuu tiettyyn liitäntään ja VPN-asiakas sovittaa paketin perusteella, kaksi päätöstä voi olla eri mieltä kummankaan olematta väärässä.

Testaa sovelluksen oma polku

Suorita uusi pyyntö sovelluksesta jokaisen muutoksen jälkeen. Selain, joka näyttää halutun ulostulon, ei ole vastaava todiste toiselle liitännälle sidotusta toisesta ohjelmasta, ja välimuistiin tallennetut yhteydet voivat käyttää vanhaa polkua kauan asetuksen muuttamisen jälkeen. Sulje vanha istunto ennen uuden säännön arvioimista. Muuten testi mittaa menneisyyttä.

Linuxin socket-viite dokumentoi SO_BINDTODEVICE-asetuksen ja sen vaatimukset. Lue ensin sovelluksen omat asetukset, toista haku samassa ympäristössä ja päätä vasta sitten, pitääkö reittiä vai sidontaa muuttaa.