L2TP NO_PROPOSAL_CHOSEN: mikä vaihe oikeastaan epäonnistui?
Ilmoitus kertoo, että ehdotus hylättiin, ei sitä mikä. Lue taustajärjestelmän lokista vaihe ja vertaa sitten sarjoja siihen, joka hallinnoi yhdyskäytävää.
NO_PROPOSAL_CHOSEN saapuu ennen kuin yhtään PPP-käyttäjänimeä tutkitaan, mikä on hyödyllinen tosiasia ja myös syy siihen, miksi viesti johtaa harhaan. Se ilmoittaa, että toinen osapuoli hylkäsi ehdotuksen; se ei ilmoita, mikä parametri oli eri mieltä, eikä kerro mitään siitä, tapahtuiko hylkäys IKE-yhteyden rakentamisen aikana vai myöhemmin liikenteen suojauksesta neuvoteltaessa. Näiden kahden mahdollisuuden takana on kaksi erilaista korjausta, ja vain toinen niistä koskee PFS-valintaruutua, johon ihmiset tarttuvat ensin.
Yksi viesti, kaksi ehdotusjoukkoa
IKEv1 L2TP/IPsec-järjestelyssä on kaksi neuvottelua peräkkäin. Vaihe 1 rakentaa IKE-turvayhteyden salausalgoritmista, eheysalgoritmista ja Diffie-Hellman-ryhmästä. Vaihe 2 neuvottelee sitten, miten liikennettä suojataan, ja PFS-vaatimus kuuluu tuohon toiseen keskusteluun.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Koska vaiheet ovat peräkkäisiä, vian sijainti kertoo, mitä luetteloa vertailla. Siinä on viestin koko diagnostinen arvo, ja se kannattaa purkaa ennen kuin koskee asetukseen.
Miksi PFS-valintaruutu ei voi korjata vaihetta 1
PFS:n poistaminen käytöstä muuttaa vaiheen 2 ominaisuutta. Jos osapuolet eivät koskaan sopineet vaiheesta 1, ESP-keskustelua ei käydä lainkaan, joten valintaruudulla ei ole mitään vaikutusta hylkäykseen, ja siksi sen vaihtaminen tuottaa saman virheen eri aikaleimalla.
Päinvastainen virhe on yhtä yleinen. Onnistunut IKE-yhteys ei todista, että ESP-ehdotus on hyväksyttävä, eikä se todellakaan todista, että vaiheen 2 ryhmä täsmää. Kohtele muodostettua hallintatunnelia todisteena vain vaiheesta 1. Ihmiset lukevat vihreän rivin tarkoittavan, että tunneli on pystyssä, ja viettävät sitten tunnin väärässä vaiheessa, koska mikään ei kertonut heille, ettei toinen neuvottelu ollut alkanut.
Lue loki ennen kuin valitset algoritmit
Kerää hylkäystä välittömästi edeltävät viestit siltä taustajärjestelmältä, joka todella käsittelee yhteyden, ja korreloi ne saman yrityksen kanssa. Ilman tätä korrelaatiota luet toisen yhteyden historiaa ja teet siitä johtopäätöksiä.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanVastaa näiden rivien perusteella kahteen kysymykseen: muodostuiko vaiheen 1 yhteys ja mikä vaihto epäonnistui. Nämä kaksi vastausta rajaavat haun yhteen attribuuttiluetteloon. Pelkkä ilmoitus ilman ympäröivää asiayhteyttä ei siihen pysty, niin houkuttelevaa kuin onkin kokeilla ehdotusta foorumiketjusta. Toimivan merkkijonon kopioiminen koneelta, jossa on eri taustajärjestelmä, korvaa yleensä yhden hylkäyksen toisella, hieman myöhemmin.
Taustajärjestelmän syntaksi ei matkusta
Kirjaa NetworkManager-l2tp:n versio ja IPsec-taustajärjestelmän versio ennen kuin vertaat mitään. Libreswan ja strongSwan eivät jaa ehdotusten syntaksia tai samoja algoritmijoukkoja, joten yhdessä toimiva merkkijono on syntaksivirhe toisessa. Asennettu taustajärjestelmä voi myös hylätä IKEv1:n käytännön perusteella, ja silloin yhtään ehdotusta ei koskaan hyväksytä.
Projektin README dokumentoi nämä taustajärjestelmien erot ja pitää vaiheen 1 ja vaiheen 2 kentät erillään. Lue se rakenteen dokumentaationa, älä kutsuna ottaa käyttöön jokaista historiallista salakirjoitusta ja heikkoa ryhmää, sillä yhteys, joka onnistuu vain niin, ei ole se yhteys, jota sinua pyydettiin rakentamaan.
Sovi sarjasta ja tarkista sitten vaiheet
Kysy yhdyskäytävän operaattorilta, mitä IKE- ja ESP-sarjoja tuetaan ja on hyväksytty, ja vertaa sitten sitä vastausta asiakkaan tehokkaisiin ehdotuksiin äläkä sen asetustiedostoon. Jos erimielisyys koskee nimenomaan vaiheen 2 PFS:ää, sovita tuettu ryhmä tai nimenomaisesti hyväksytty käytäntö ilman PFS:ää. Älä päättele käytäntöä virheen nimestä.
Kun ainoa päällekkäisyys vaatii salausta, jota organisaatio ei enää hyväksy, päätös kuuluu yhdyskäytävälle tai protokollan siirrolle. Asiakkaan merkkijonon leventäminen kunnes jokin neuvottelee on tapa toimittaa tunnettu heikkous vihreällä valintamerkillä varustettuna.
Kun olet korjannut todellisen eron, vahvista IPsecin muodostuminen ennen kuin tutkit L2TP:tä ja PPP:tä, ja kohtele myöhempää todennuksen hylkäystä seuraavaan vaiheeseen kuuluvana. Testaa sitten uusiminen hyväksytyssä testiprosessissa, sillä ensimmäisen yhteyden muodostaminen ei kerro mitään sen loppuelämästä.