Dvostruki NAT i vaš VPN: klijent radi, server ne
Dva rutera koja prevode adrese retko zaustavljaju odlazni VPN klijent. Hostovanje servera iza njih je teže, posebno kada je spoljni sloj carrier-grade NAT.
Vaš ruter stoji iza drugog rutera, WAN adresa je privatna, a VPN klijent se ipak povezuje. Ta kombinacija iznenađuje ljude koji očekuju da će dvostruki NAT pokvariti tunele, ali odlazne veze su upravo ono što prevođenje najbolje rešava. Hostovanje VPN servera iza istih tih dvaju slojeva je slučaj koji obično propada. Nacrtajte smer veze pre nego što bilo šta promenite.
Prvo nacrtajte smer veze
Otvorite statusnu stranicu unutrašnjeg rutera i zapišite njegovu WAN adresu, pa je uporedite sa adresom koju vam prijavi javna usluga. Ako se dve razlikuju, između vašeg rutera i interneta stoji barem jedan prevodilac. Ako WAN adresa pada unutar 100.64.0.0/10, spoljni prevodilac verovatno pripada vašem provajderu i vi ga ne kontrolišete. Te dve činjenice odlučuju koji od kasnijih koraka uopšte može uspeti.
curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1
Dvostruki NAT nije dvostruki VPN. Prevođenje prepisuje adrese i portove; ono ne dodaje drugi šifrovani tunel i ništa ne šifruje. Razdvajanje tih dviju ideja je važno jer su rešenja potpuno različita, a jedno od njih uključuje razgovor sa vašim provajderom, a ne stranicu sa postavkama.
Odlazni smer: klijent pita, prevodioci mapiraju
Odlazni tunel počinje paketom sa vaše mašine, pa svaki prevodilac može stvoriti mapiranje i pustiti odgovor natrag. Protokol, port i tajmeri mirovanja odlučuju hoće li to mapiranje preživeti dovoljno dugo da bude korisno. Većina potrošačkih rutera to rešava bez ikakve konfiguracije.
Kvarovi koji se zaista pojavljuju obično se tiču vremenskih ograničenja i podrške za protokole, a ne broja rutera. Tunel koji padne nakon nekoliko minuta tišine je mapiranje koje ističe, a keepalive je standardni odgovor. IPsec ima standardna NAT-traversal proširenja, pa je tvrdnja da ne može proći kroz prevođenje jednostavno netačna. Ako se tunel uopšte ne uspostavi, pogledajte krajnju tačku i akreditive pre nego što okrivite topologiju.
wg show
ping -c3 10.8.0.1
Zaustavite se ako odlazni tunel radi sa jedne mreže, a sa druge ne. To poređenje se odnosi na mreže, a ne na broj rutera.
Dolazni smer: prosleđivanje pokriva samo opremu koju posedujete
Hostovanje servera je obrnut smer: nova veza dolazi sa interneta i mora doći do vaše mašine kroz svaki sloj. Pravilo za prosleđivanje porta na unutrašnjem ruteru pomaže samo ako i spoljni prevodilac taj saobraćaj dostavi vama. Ponavljanje lokalnog pravila ne daje kontrolu nad opremom provajdera.
nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'
Uporedite WAN adresu unutrašnjeg rutera sa javnom adresom koju ste primetili i zabeležite odakle dolazi svaka vrednost. Ako je WAN adresa privatna ili u deljenom opsegu, spoljni sloj obavlja prevođenje koje ne možete konfigurisati. Pitajte provajdera koju dolaznu dostupnost podržava pre nego što potrošite celu večer na pravila koja ne mogu stupiti na snagu. Uklanjanje rutera ili široko isključivanje firewall-a nije dijagnoza i loša je trgovina za jedan otvoreni port.
Zaustavite se ako spoljni sloj pripada provajderu i ne prosleđuje. Tada su podržani odgovori drugi način pristupa ili relay, a ne još jedno pravilo na vašoj strani.
Testirajte jednu varijablu odjednom
Menjajte jednu stvar po testu i beležite rezultat, jer put sa dvostrukim NAT-om ima više varijabli od puta sa jednim ruterom. Držite profil i uređaj fiksnima, pa uporedite drugu pristupnu mrežu. Zabeležite da li pregovaranje ne uspeva, da li sesija pada nakon mirovanja ili da li ne uspevaju samo privatna odredišta. Ta tri zapažanja upućuju na tri različita sloja.
journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40
Preklapajuće privatne podmreže su odvojena zamka koju nikakva količina prevođenja ne ispravlja. Ako vaša kućna mreža i udaljena mreža koriste isti opseg, sukob ruta se pojavljuje bez obzira na to koliko prevodilaca stoji između. Prenumerisanje jedne strane jedini je trajni odgovor.
Udaljeni gateway zaslužuje istu pažnju, jer njegova pravila prosleđivanja i povratne rute mogu biti deo koji nedostaje. Tunel koji prođe autentifikaciju i dalje može nemati upotrebljivu putanju za aplikacije, a taj kvar sa klijentske strane izgleda identično. Šetnja se završava kada možete reći koji smer ne radi i koji sloj je za njega odgovoran.