Dva VPN skoka na jednom Pi: koja ruta nosi koji peer

Dvije adrese tunela na jednoj maloj ploči izgledaju kao greška, a refleks je izbrisati jednu. Taj refleks kvari ono što je trebalo pospremiti. Host koji nosi dva skoka drži po jednu adresu za svaki priključak, a svaku adresu bira druga ruta. Pitanje koje vrijedi postaviti je koja ruta bira koji nositelj za koje odredište, a ne koliko adresa postoji.

Tri odredišta kojima trebaju različiti nositelji

Lanac od dva skoka su tri klase odredišta naslagane jedna na drugu, a svaku nosi drugi priključak. Vanjski peer mora se dosegnuti preko fizičke veze. Unutrašnji peer mora se dosegnuti kroz vanjski tunel. Odredište pokrivene aplikacije mora se dosegnuti kroz unutrašnji tunel, čiji vlastiti transport nosi vanjski.

Popunite redove stvarnim adresama čitatelja prije nego što dirnete rutu, jer je tablica korisna samo kad je konkretna. Ispravan lanac zadovoljava sva četiri retka istovremeno, a poluispravan obično zadovoljava jedan od njih s pogrešnim nositeljem. Upravo čitanje pogrešnog retka kao kvara pretvara problem usmjeravanja u cijelu večer uređivanja.

Adrese imaju uloge, ne broj

Linux dopušta nekoliko adresa na jednom sučelju i nekoliko tunela na jednom hostu, pa broj ne govori ništa o ispravnosti. Važno je koja adresa pripada kojem priključku i bira li ruta za određenog peera priključak koji ste mislili. Tri pogleda odgovaraju na to iz tri smjera i vrijedi ih čitati istim redoslijedom svaki put.

Popis adresa pokazuje što postoji i koji priključak ga posjeduje. Tablica ruta odgovara na pitanje nositelja za običan promet prema odredištima. Pogled pravila odgovara na njega ponovno za promet odabran izvorom ili oznakom, što je uobičajen raspored kad dva klijenta dijele jedan host.

ip -4 addr show
ip -4 route show table all
ip rule show

Brisanje adrese jer popis izgleda dugačko može ukloniti dio puta, a brisanje rute jer izgleda suvišno čini isto tiše. Nijedno ne daje grešku; peer jednostavno prestane odgovarati na putu koji ste namjeravali, dok ostaje dostupan drugim putem. Aplikacija koja prijavljuje izlaznu adresu unutrašnjeg peera ne dokazuje da je promet prešao vanjski tunel, jer izravan pristup daje isto opažanje. Taj jaz između opažanja i dokaza razlog je zašto se nositelj provjerava na sloju usmjeravanja.

Redoslijed aktivacije pobjeđuje fiksno čekanje

Ako unutrašnji klijent ovisi o adresi ili ruti koju osigurava vanjski klijent, aktivacija mora čekati taj resurs, a ne odgodu. Čekanje radi do dana kad je vanjski tunel spor, a tada povremeno zataji na način koji nitko ne može reproducirati. Redoslijed zasnovan na ovisnostima uklanja nagađanje i ne košta ništa osim jednog opisa ovisnosti. Ni imena sučelja nisu mehanizam za redoslijed.

Jezgra dodjeljuje imena poput tun0 i tun1 redoslijedom stvaranja, a taj se redoslijed može promijeniti između ponovnih pokretanja ili povezivanja. Vežite konfiguraciju na identitet koji alat pruža ili na ime koje svjesno dodijelite. Ime koje odaberete je ugovor; ime koje odabere jezgra je slučajnost.

Držite transport svakog klijenta izvan aplikacijske rute onog drugog i budite precizni o tome što OpenVPN 2.6 opcije usmjeravanja doista obećavaju. Dokumentirani mehanizam zadanog preusmjeravanja održava klijenta sposobnim dosegnuti vlastiti udaljeni peer kroz pristupnik koji je već postojao, što prekida jednu specifičnu rekurzivnu petlju. On ne pretvara jedan klijent u nositelja drugog, pa ostatak lanca ostaje vaš dizajn. Gdje lanac treba pravilo, a ne rutu, napišite izričito pravilo izvora ili oznake i testirajte ga prometom kojem je namijenjeno.

Što se događa kad vanjski skok umre

Prije nego se lanac računa dovršenim, odlučite što se događa kad vanjski skok nestane. Transport unutrašnjeg klijenta umire s njim, a sljedeći potez je pitanje pravila, a ne tehnike: neuspjeh, ponovni pokušaj ili izravno ponovno povezivanje preko fizičke veze. Treći ishod je onaj o kojem vrijedi razmisliti. On tiho pretvara dizajn s dva skoka u dizajn s jednim skokom u trenutku kad korisnik vjeruje da je pokrivenost još netaknuta.

Ako su dva skoka obavezna, unutrašnji klijent ne smije moći uspostaviti izravan put kad vanjskog nema, a način da to saznate je prekinuti vanjski skok i promatrati što unutrašnji radi. Odobreni rezervni put legitiman je odgovor, ali mora biti zapisan, testiran i priopćen. Rezervni put koji nitko nije dokumentirao ne razlikuje se od curenja tijekom pregleda incidenta.

DNS i druga obitelj adresa pripadaju istoj odluci. Lokalno generirano traženje slijedi vlastita pravila hosta, a ne pravila proslijeđenog klijenta, pa resolver koji radi za proslijeđeni promet možda nije onaj koji sam host koristi.

Prihvatite svaki sloj redoslijedom kojim ste ga gradili

Testirajte redoslijedom kojim je lanac građen: prvo sam vanjski tunel, zatim transport unutrašnjeg klijenta kroz vanjski tunel, zatim aplikaciju kroz unutrašnji tunel. Svako prihvaćanje mora biti nova veza, a ne stranica koja je već bila otvorena. Zatim prekinite i obnovite svaki sloj zasebno i promatrajte što sljedeći radi.

Rezultat rezervnog puta najvrjednije je opažanje ovdje i ono koje stranica s javnom IP adresom nikad ne pokaže. Spremite putanje peera, adrese koje koriste i taj ishod uz konfiguraciju, jer sretan put nije dio koji se kasnije preispituje.