MULTI: virheellinen lähiosoite asiakkaalta: kenen osoite se oli?
Sisäinen lähde ei vastaa asiakasta, joka sen toimitti. Sovita se tunnelimääritykseen, asiakkaan takana olevaan LAN-verkkoon tai kaksoiskappaleena olevaan identiteettiin.
Palvelimen loki tulostaa MULTI: bad source address from client, pudottaa paketin ja istunto pysyy yhdistettynä. Tämä yhdistelmä hämmentää niitä, jotka lukevat viestin todennuksen epäonnistumisena. Se ei ole sitä: asiakas on todennettu, ja saapunut paketti kantoi sisäistä lähiosoitetta, jota palvelin ei pystynyt yhdistämään tähän asiakasinstanssiin. Tarkistus tapahtuu ennen toimitusta, ja siksi tunneli näyttää terveeltä, vaikka mikään hyödyllinen ei kulje sen läpi.
Mitä palvelin vertaa ennen toimitusta
Jokaiselle asiakkaalta saapuvalle paketille käyttäjäavaruuden palvelin katsoo tunnelin sisäistä lähiosoitetta ja kysyy sisäiseltä reititystilaltaan, mille asiakkaalle tuo osoite kuuluu. Jos omistaja on toinen instanssi tai omistajaa ei ole lainkaan, paketti hylätään ja varoitus annetaan.
Tavallinen toimitus tunnelin rajapinnan kautta ei tapahdu koskaan.
Tämä järjestys selittää yksityiskohdan, joka hämmentää ihmisiä: isäntäkoneen palomuurin laskurit eivät liiku, koska paketti ei koskaan saavuttanut palomuuria. Paluupolun suodatuksen säätäminen isäntäkoneella ei muuta täällä mitään, koska hylkäys tapahtui daemonin omassa liitostarkistuksessa. Lue viesti väitteenä omistajuudesta ja selvitä sitten, mikä kolmesta tilanteesta sen tuotti.
Kolme yhteensopimattoman sisäosoitteen lähdettä
Asiakas voi lähettää osoitteesta, jota sille ei määrätty, verkosta, jota kukaan ei julistanut sen omaksi, tai sellaisen identiteetin kaksoiskappaleesta, jolla on jo omistaja. Kaikki kolme tuottavat saman lokirivin. Ne eroavat siinä, mitä sinun on muutettava. Aloita osoitteesta ja nykyisestä määrityslistasta ja anna näiden kahden tosiasian valita tapaus.
Niiden erottaminen vaatii kaksi tosiasiaa: lokissa hylätty osoite ja määritykset, joita palvelin pitää nykyisinä. Toinen on saatavilla käynnissä olevan instanssin tila- tai hallintanäkymästä, ja se on ainoa taho, jota kannattaa kuulla, koska asetustiedosto tallentaa aikomuksia eikä nykyistä tilaa.
Kirjaa molemmat ennen kuin muutat mitään, ja luokittele sitten. Myöhemmin otettu kuvakaappaus ei ole sen tilan tallenne, joka varoituksen tuotti. Säilytä myös aikaleima, koska määritykset siirtyvät istuntojen välillä.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
Asiakkaan takana oleva LAN ja iroute
Kun sivuston asiakas reitittää omaa yksityisverkkoaan, se verkko on julistettava asiakkaalle kuuluvaksi. Asiakaskohtainen tiedosto, jossa on iroute-merkintä, tekee sen, ja merkintä nimeää etuliitteen, jonka asiakas saa kuljettaa.
Ytimen reitti, joka osoittaa saman etuliitteen tunneliin, on erillinen vaatimus, eikä sen lisääminen muuta mitään daemonin sisäisessä omistajuudessa.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Varmista, että tehollinen identiteetti vastaa tiedoston nimeä, sillä poikkeama tarkoittaa, ettei tiedostoa koskaan ladata, ja oire on sama kuin puuttuvassa merkinnässä. Älä lisää laajaa iroutea vaientaaksesi varoitusta, sillä se muuttaa odottamattoman lähteen valtuutetuksi vastaamatta siihen, miksi asiakas sen lähetti. OpenVPN 2.6 -käsikirja dokumentoi irouten, duplicate-cn:n ja identiteetin yhdistämisen erillisinä kontrolleina.
Sama identiteetti kahdessa koneessa
Toiselle kannettavalle kopioitu profiili kantaa saman varmenteen ja saman yleisnimen. Palvelimen asetuksista riippuen uudempi yhteys voi korvata vanhemman, ja se instanssi, jolla on omistajuus, voittaa liitostarkistuksen.
Tämä saa vian näyttämään ajoittaiselta ja ilmestymään vain, kun molemmat laitteet ovat hereillä.
Kaksoiskappaleisten yleisnimien salliminen päästää molemmat yhdistämään, mutta ei anna niille erillisiä staattisia osoitteita tai erillistä omistajuutta. Jos kahden laitteen on oltava olemassa yhdessä, rekisteröi ne erikseen, jotta kummallakin on oma identiteettinsä ja oma määrityksensä. Kaksoisasetuksen pitäminen tämän varoituksen korjauksena jättää arvoituksen paikoilleen ja lisää toisen.
Todista, että liitos muuttui
Toteuta korjaus asetusten omistajan kautta ja yhdistä sitten kärsinyt asiakas uudelleen, jotta uusi käytäntö latautuu.
Toista sama kulku ja varmista kolme asiaa: paketin sisäinen lähde, asiakasinstanssi, johon palvelin sen liittää, ja kohteen käyttäytyminen sen jälkeen.
Jos varoitus loppuu mutta sovellus epäonnistuu edelleen, ongelma siirtyi eikä kadonnut. Edelleenlähetys, palomuurisäännöt ja paluupolku ovat erillisiä vaiheita, ja liitostarkistuksen läpäisy tarkoittaa vain, että paketti sai lähteä tunnelista.