Sekva salto en VPN-itinero: kial la kluzo devas esti loke atingebla
La via-adreso de itinero devas esti atingebla sur la ligo, de kiu vi sendas. Spuru la transdonon, kontrolu la serĉon kaj testu de la gastiganto, kiu posedas la trafikon.
Itinero en VPN-reton portas du adresojn, kiujn oni facile konfuzas: la celan prefikson, kiun la pakaĵo provas atingi, kaj la sekvan salton, kiu movos ĝin unu paŝon pli proksimen. Sur LAN-gastiganto tiu sekva salto devas esti enkursigilo, kiun vi vere povas atingi sur la sama ligo. La fora VPN-adreso ne estas sekva salto, kiom ajn bone ĝi kongruas kun la celo, kiun vi havas en la kapo.
Ĉi tiu manlibro kovras la ordinaran kazon: tekkomputilo ĉe 192.168.20.0/24, VPN-kluzo kun LAN-adreso 192.168.20.5 kaj fora reto 10.70.0.0/24 malantaŭ tiu kluzo. Ĉiuj subaj komandoj supozas, ke vi estas ĉe la tekkomputilo, se ne dirite alie.
Du adresoj, unu itinero
La celata enskribo estas 10.70.0.0/24 via 192.168.20.5. La prefikso diras, kien la pakaĵo iras; la via-adreso diras, kiu portas ĝin tien. La kerno rifuzas instali itinerojn, kies kluzon ĝi ne povas atingi tra la interfaco, kiun vi nomas, kaj tiu rifuzo estas la tuta senco: sekva salto, kiu bezonas la tunelon por esti atingebla, ne povas esti la sekva salto, kiu konstruas la tunelon.
Do la unua kontrolo ne estas «ĉu la kluzo funkcias» sed «ĉu la kluzo estas sur ĉi tiu ligo». La propra subreto de la tekkomputilo, ĝia ARP- aŭ najbara enskribo kaj la interfaco en la itinero devas ĉiuj kongrui. Adreso, kiu ekzistas nur ene de 10.70.0.0/24, povas esti celo de dua itinero, neniam via de la unua.
Al kio la sekva salto devigas la kluzon
Instali la itineron sur la tekkomputilo decidas nur la unuan transdonon. Poste la kluzo bezonas sian propran vojon: ŝaltita plusendo, tunela itinero por 10.70.0.0/24 kaj ajna alirpolitiko, kiu reguligas, kiu rajtas uzi ĝin. En Linux tio estas net.ipv4.ip_forward=1 plus tunela itinero; fajroŝirmilo antaŭ ĝi bezonas regulon, kiu permesas la plusendatan fluon.
La revena direkto estas la parto, kiun homoj forgesas. La fora flanko devas havi itineron reen al 192.168.20.0/24, aŭ la dezajno devas traduki la fonton de la tekkomputilo en ion, kion la fora flanko konas. Funkcianta ping de la kluzo pruvas, ke la kluzo povas atingi la foran reton; ĝi diras nenion pri tio, ĉu la pakaĵoj de la tekkomputilo postvivas la revenan vojaĝon.
Kontrolu la serĉon de la gastiganto, kiu sendas
Demandu la kernon, kiun sekvan salton ĝi elektus, kaj legu la interfacon en la respondo:
ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5
Se la serĉo raportas la kluzon kaj la LAN-interfacon, la unua parto estas agordita laŭ la intenco. Se ĝi raportas la tunelan aparaton, io pli frue en la tabelo estas pli specifa kaj venkas. Se la itinero tute ne instaliĝas, la kerno diras al vi, ke la kluzo ne estas atingebla, kaj tiu mesaĝo estas pli utila ol ajna pakkaptado.
Poste ripetu la teston de la ĝusta loko. Peto kreita sur la kluzo uzas la propran fontadreson de la kluzo, kio povas kaŝi mankan revenan itineron aŭ politikon, kiu permesas nur certajn fontojn. La manlibro de ip-route apartigas celon, kluzon kaj la anstataŭigon onlink, kaj la anstataŭigo indas esti komprenata antaŭ ol vi uzos ĝin.
Ne uzu onlink por ŝajnigi atingeblon
onlink diras al la kerno preterpasi la atingeblan kontrolon por kluzo kaj tamen sendi al ĝi. Ĝi ne kreas vojon, ne solvas ARP por adreso, kiu ne estas tie, kaj ne igas foran enkursigilon respondi sur via Ethernet-segmento. Ĝi estas legitima por kluzoj, kiuj respondas sed ne sidas en konektita subreto, kaj ĝi estas kaptilo, kiam oni uzas ĝin por silentigi eraron, kiun vi ne klarigis.
Se la itinero instaliĝas nur kun onlink, la sekva demando estas, kial la kluzo ne estas tie, kie vi pensas. Malĝusta VLAN, dua adreso sur la malĝusta interfaco aŭ tajperaro en la lasta okteo ĉiuj produktas tion, kaj ĉiu el ili ankaŭ rompas la revenan vojon, kiam la trafiko ekfluas.
Punkt-al-punkta tuneloj ne estas Ethernet
Tunela aparato ne faras ARP kaj ofte ne havas senchavan subreton de najbaroj. Ĝiaj itineroj ofte aspektas kiel 10.70.0.0/24 dev tun0, sen ajna via, ĉar la samtavolano estas la sola alia finpunkto. Kopii via laŭ LAN-stilo en tiun tabelon produktas itineron, kiun la kerno povas malakcepti aŭ, pli malbone, unu kiu montras al adreso, al kiu la samtavolano neniam respondas.
Tenu la du modelojn aparte en la manlibro: LAN-itinero havas atingeblan kluzon, tunela itinero havas interfacon kaj samtavolanon. WireGuard, OpenVPN kaj IPsec ĉiuj montras iom malsamajn formojn, do notu la formon, kiun vi efektive uzis, anstataŭ ĝeneraligi el unu gastiganto.
Aldonu, konfirmu, malfaru
La tuta ŝanĝo estas tri komandoj kaj unu kontrolo, kaj ĝi devas esti skribita en tiu ordo:
sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5
Konfirmu la vojon, konfirmu unu celon, kaj poste tenu la forigan linion preta, se la ŝanĝo igos la gastiganton neatingebla tiel, kiel vi ne antaŭvidis. Se la itinero devas postvivi restartigon, metu ĝin en la retan agordon de la gastiganto anstataŭ en ŝelan profilon, kaj testu la restartigon antaŭ ol vi fidos ĝin. Itinero, kiu ekzistas nur en la ŝelo, kiu aldonis ĝin, estas itinero, kiun vi sencimigos dufoje.