Vieras-VPN ja isäntä-VPN: mikä reitti oikeasti voittaa
Kaksi asiakasta, kaksi oletusreittiä ja yksi hämmentävä oire. Kirjaa vieraan liitostapa, seuraa sen päätepistettä ulospäin ja muuta sitten yhtä muuttujaa kerrallaan.
Kaksi asiakasta toimii samaan aikaan, kumpikin vakuuttuneena siitä, että omistaa oletusreitin, ja oire ilmenee jonakin outona: yksi vieraan sovellus toimii, toinen ratkeaa väärään paikkaan. VPN vieraan sisällä ja VPN isännässä voivat elää rinnakkain, mutta vain kun ulompi polku ja sisempi käytäntö ovat yhtä mieltä siitä, kuka kantaa mitäkin. Molempien käynnistäminen ei sinänsä luo ketjua. Kirjaa ensin liitostapa ja muuta sitten yhtä asiaa kerrallaan.
Kirjaa ensin vieraan liitostapa
Vieras tavoittaa VPN-palvelimensa sitä polkua pitkin, jonka hypervisor sille antoi: NAT isännän takana, silta fyysiseen segmenttiin tai vain isännälle tarkoitettu verkko, jonka päälle reititys on lisätty. Jokainen liitostapa muuttaa sitä, mitä vieras voi nähdä ja mitä isäntä voi tehdä sen liikenteelle. NAT:n alla vieraan paketit näyttävät tulevan isännästä, joten isännän oma tunneli voi kuljettaa ne vieraan tietämättä asiasta mitään. Sillan alla vieraalla on oma läsnäolonsa segmentissä ja oma oletusyhdyskäytävänsä.
Kirjaa liitostapa ennen kuin kosket mihinkään asetukseen, yhdessä sen kanssa, minkä asiakkaan pitäisi kantaa mitäkin sovellusta. Se lause ratkaisee useimmat näistä tapauksista, koska kaksi asiakasta rakennetaan yleensä erilaisille oletuksille. Vieras, jonka odotetaan käyttävän isännän tunnelia, ei saa myöskään omistaa kilpailevaa oletusreittiä.
Seuraa vieraan päätepistettä ulospäin
Vieras-VPN tarvitsee käyttökelpoisen polun omaan palvelimeensa ennen kuin mikään muu voi toimia. Kun isännän tunneli on ylhäällä ja vieras istuu NAT:n takana, vieraan kättely lähtee isännän tunnelin kautta, mikä on joko suunnittelua tai onnettomuus, jota kukaan ei dokumentoinut. Kun isännän tunneli putoaa ja vieras oli siitä riippuvainen, vieras menettää yhteyden ilman yhtäkään muutosta omalla puolellaan. Päätepisteen seuraaminen ulospäin kertoo, kumpi näistä kahdesta sinulla todella on.
Laaja reitti kummassa tahansa yhteydessä kaappaa liikennettä, jota toinen asiakas odotti. Vieraan sisällä oleva 0.0.0.0/0-reitti ja täystunnelin isäntäasiakas vaativat molemmat kaikkea, ja se voittaa, joka pätee viimeisenä. Vieraan virtuaaliverkkojen, paikallisen LAN-verkon ja etäverkkojen päällekkäisyydet tuottavat saman vaikutuksen yksityisille etuliitteille, ja viat muistuttavat todennusongelmia; osoitteenmuunnoksen käyttäytyminen on sama, joka kuvataan kohdassa säilöverkot.
Vertaa ennen ja jälkeen -kirjausta
Ota perustaso isännän tunneli pois päältä tai missä tahansa hallitussa tilassa, jonka käytäntösi sallii, ja kirjaa vieraan reitti ja resolveri. Käytä sitten yhdistettyä asetusta ja vertaa kahta kirjausta pitäen yksityisyysvaatimukset ennallaan. Jos suora perustaso ei ole sopiva, kirjoita se rajoitus kirjaukseen sen sijaan, että jättäisit vertailun väliin.
ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12
Reittikysely nimeää rajapinnan ja lähdeosoitteen, jotka kuljettaisivat tietyn kohteen, ja se on tämän tutkinnan hyödyllisin yksittäinen rivi. Sääntöluettelo näyttää, lähettääkö käytäntöpohjainen reititys joitakin kohteita toisen taulukon kautta. Resolverin tuloste näyttää, seurasiko DNS vieraan tunnelia vai jäikö se isännän polulle. Aja samat kolme komentoa ennen muutosta ja sen jälkeen, ja ero nimeää syyllisen.
Pidä omistajuus selvänä uudelleenkäynnistysten yli
Isäntäasiakkaan paikallisen pääsyn rajoitus voi estää liikenteen virtuaaliseen NATiin tai siltaan, ja tämä rajoitus sekoitetaan säännöllisesti vieraan tunnistetieto-ongelmaan. Lue asiakkaan dokumentoitu käyttäytyminen sen sijaan, että kytkisit rajoituksen pois testin läpäisemiseksi. Tuetun korjauksen jälkeen testaa uudelleen vieraan sovellus ja vaatimasi vikatilakäytäntö. Isäntä, joka yhdistyy onnistuneesti uudelleen, ei todista mitään vieraan reitistä tai resolverista.
Päätä, kumpi puoli omistaa oletusreitin, ja kirjoita se käyttöohjeeseen. Vieraan uudelleenkäynnistys tai isännän verkonvaihto, joka kääntää omistajuuden äänettömästi, tuottaa virheraportin VPN:stä, joka ei ollut koskaan syyllinen. Järjestelyn pitäisi kestää uudelleenkäynnistys ilman, että kukaan muistaa, miksi se toimi.